Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3FC15E1C.5000107@netscape.net>
Date: Sun, 23 Nov 2003 20:25:48 -0500
From: Nicholas Wourms <nwourms AT netscape DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: cygwin AT sources DOT redhat DOT com
Subject: Possible bug with __attribute__((alias)) in gcc-3.3
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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:

foo.c:
#include <stdio.h>

int __foo (void) {
    printf("foo\r\n");
    return 0;
}
int __attribute__ ((alias("__foo"))) foo (void);

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

int main (void) {
     foo();
     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:
./bar

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:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01281.html

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.

Cheers,
Nicholas


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/