glibc 2.1.3 + gcc 4.1.1 patch (x86) working, except for static

["Gerry JJ" <trick at icculus dot org>]

(Please CC replies to me as I'm not subscribed to the list)

Hello!

The attached patch makes glibc 2.1.3 compile with gcc 4.1.1 for x86 (i586  
tested).  It probably still needs some fixes to compile for other archs.   
It should be applied after the other crosstool patches for glibc 2.1.3.   
There's two gotcha's, though:

* Two strong aliases, 'strong_alias (__old_sys_siglist, _old_sys_siglist)'  
and 'strong_alias (__old_sys_errlist, _old_sys_errlist)', have been  
commented out.

gcc complained that these were aliases to an nonexistant symbol, while the  
symbol is in fact defined in assembly in the same source file (unless I'm  
missing something ?).  I didn't know how to fix this, so I just commented  
the aliases to make it compile.  These are marked with FIXME in the  
patch.  This should only affect run-time compatibility with GLIBC 2.0, so  
I don't think it should affect compiling of new code with this setup (but  
please correct me if I'm wrong).

* Statically compiled executables segfault (executables dynamically linked  
to libc work fine)

This is probably a much bigger problem, and I'm not sure how to fix it.   
The segfault happens at __libc_start_main+18 in this code:

(gdb) disassemble
Dump of assembler code for function __libc_start_main:
0x08048220 <__libc_start_main+0>:       push   %ebp
0x08048221 <__libc_start_main+1>:       mov    %esp,%ebp
0x08048223 <__libc_start_main+3>:       push   %edi
0x08048224 <__libc_start_main+4>:       push   %esi
0x08048225 <__libc_start_main+5>:       push   %ebx
0x08048226 <__libc_start_main+6>:       sub    $0xc,%esp
0x08048229 <__libc_start_main+9>:       mov    0xc(%ebp),%esi
0x0804822c <__libc_start_main+12>:      mov    0x10(%ebp),%ebx
0x0804822f <__libc_start_main+15>:      mov    0x1c(%ebp),%edi
0x08048232 <__libc_start_main+18>:      cmpl   $0x0,0x0
0x08048239 <__libc_start_main+25>:      sete   %al
0x0804823c <__libc_start_main+28>:      and    $0xff,%eax
0x08048241 <__libc_start_main+33>:      mov    %eax,0x8077ce0
0x08048246 <__libc_start_main+38>:      mov    0x20(%ebp),%eax
0x08048249 <__libc_start_main+41>:      mov    %eax,0x80791bc
0x0804824e <__libc_start_main+46>:      lea    0x4(%ebx,%esi,4),%eax
0x08048252 <__libc_start_main+50>:      mov    %eax,0x80789c0
0x08048257 <__libc_start_main+55>:      cmpl   $0x0,0x8077cdc
0x0804825e <__libc_start_main+62>:      je     0x8048265  
<__libc_start_main+69>
0x08048260 <__libc_start_main+64>:      call   0x80482fc  
<check_standard_fds>
0x08048265 <__libc_start_main+69>:      test   %edi,%edi
0x08048267 <__libc_start_main+71>:      je     0x8048275  
<__libc_start_main+85>

The cmpl is comparing to a value at 0x0, so no wonder it segfaults.  The  
question is, why ?  Some problem with the linker ? The patch do modify  
dl-load.c, but the fix is identical to code from glibc-2.3.6, so that one  
should be ok.

Does anyone know what might cause this ?

- Gerry

Attachment: glibc-2.1.3-gcc4.patch
Description: Binary data

--
For unsubscribe information see http://sourceware.org/lists.html#faq