This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Possible bug with __attribute__((alias)) in gcc-3.3

Hi All,

Gerrit and I were discussing this off-list, but I thought it appropriate that I move it to the main list since he has confirmed the problem.

Here's the problem, programs are segfaulting when the are linked to a symbol which was aliased using __attribute__((alias)) in a dll. Here is a small testcase:

#include <stdio.h>

int __foo (void) {
   return 0;
int __attribute__ ((alias("__foo"))) foo (void);

#include <stdio.h>
extern int foo (void);

int main (void) {
    return 0;

Then compile as:
gcc -shared -o cygfoo.dll foo.c -Wl,--out-implib=libfoo.dll.a
gcc -o bar.exe bar.c -L. -lfoo

Then run:

Which should return:
Segmentation fault (core dumped)

Running this same test, modifying the compiler args as needed, on Linux results in success. Of course, Linux is ELF, so you really can't draw any strong conclusions from this exercise.

However, Danny's message to the gcc mailing list:

seems to indicate that __attribute__((alias)) is supposed to work for 32bit PE targets. In fact, Danny's message is about a presumably "unrelated" MinGW problem with that same function attribute. Gerrit says he's going to give the patch in that message a try (I'm low on space so I can't build a new toolchain) and see if it helps in any way.

What I'd like to know is if this function attribute is supposed to work on native cygwin targets? If so, is there something wrong with how I'm going about it? I can only speculate that the auto-import warning I get might have something do with it? It doesn't seem like a situation where auto-import ought to be necessary, but I could be wrong.

In case people were curious, my thoughts were to setup "faux" weak-alias support for Cygwin by implementing the weak-alias macro glibc uses with this attribute. The only difference being that there would be no __attribute__((weak)) and no LD_PRELOAD support, since neither are currently support for 32bit PE's. However, it would paper over an aggravating problem caused by elf-centric software. Software which insists on making global functions as weak references to underscored functions with other software expecting both symbols to be present in the shared library. The nice part of this method is that it wouldn't require inserting nasty ifdefs or fiddling with def files, rather using a macro which is already present in the offending source.


-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]