[parisc-linux] glibc is broken because of gcc

[Sébastien Bernard]

John David Anglin a écrit :
>> Here is the readelf of the broken build :
>> seb at hpnux:~/glibc-2.5/build-tree/hppa-libc/rt$ readelf -a ./libc.so 
>> |grep multiple_threads
>>    1230: 0013e328     4 OBJECT  GLOBAL DEFAULT   32
>> __librt_multiple_threads@@GLIBC_PRIVATE
>>    2737: 0013e328     4 OBJECT  LOCAL  HIDDEN   32 __libc_multiple_threads
>>    3961: 0013e328     4 OBJECT  GLOBAL DEFAULT   32 __librt_multiple_threads
>>
>> seb at hpnux:~/dev/glibc/glibc-2.5/build-tree/hppa-libc/rt$ readelf -a
>> librt_pic.a |grep multiple_threads
>>      18: 00000000     0 NOTYPE  GLOBAL HIDDEN  UND __librt_multiple_threads
>>       6: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __librt_multiple_threads
>>       6: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __librt_multiple_threads
>>
>> I don't see anything wrong. Moreover, the readelf on the correct library 
>> gives exactly the same result.
> 
> The error in bug 428509 is:
> 
> ...
> /home/seb/dev/glibc-2.5/build-tree/hppa-libc/rt/librt_pic.a(mq_timedreceive.os):(.text+0x20): more undefined references to `__librt_multiple_threads' follow
> /usr/bin/ld: /home/seb/dev/glibc-2.5/build-tree/hppa-libc/rt/librt.so: hidden symbol `__librt_multiple_threads' isn't defined
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> 
> Looking at gcc PR 20218, it's clear that there are some very subtle
> issues here.  So, it's not clear to me where the problem lies.  It
> could be in glibc (hppa sysdep-cancel.h), binutils or gcc.  The handling
> of the visibility attribute was broken prior to HJL's change, so it
> could have exposed bugs in other packages.
> 
> Because of this, it was a mistake for Debian to backport this change.
> The change is only in the unreleased gcc trunk.
> 
> Since the problem was introduced by a gcc change, I'd start with
> a gcc PR and mention the patch that introduced the regression.
> 
> Could you do glibc builds with the gcc trunk before and after the change?
> It's best to base the PR on an unmodified version of gcc.
> 
> It would help to know the exact details of the linker command that
> fails, the assembler code generated for mq_timedreceive, and the
> __librt_multiple_threads symbols in __librt_multiple_threads librt.so.
> 
> Dave
Here is the detail of the link command done with gcc-4.1-4.1.2-13.

It's not clear want do you want exactly.

I join the result of :
   objdump -d mq_timedreceive.os
   readelf -a libc-cancellation.os
   readelf -a mq_timedreceive.os

Hope this is what you're asking for.

Seb

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dump.objdump_timedreceive
Url: http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/20070703/29f98071/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dump.readelf_libc-cancel
Url: http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/20070703/29f98071/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dump.readelf_timedreceive
Url: http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/20070703/29f98071/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.link
Url: http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/20070703/29f98071/attachment-0003.txt