[Bug ld/5905] New: 'version node not found for symbol ...' during linking against libc_pic.a
please consider following testcase:
$ cat bug.cpp
void f() { }
$ g++ -fpic bug.cpp -o libbug.so -shared -z defs \
-nodefaultlibs -nostartfiles -lsupc++ libc_pic.a
imho it should work fine, but linker produces an error:
/usr/bin/ld: libbug.so: version node not found for symbol
pthread_cond_destroy@@GLIBC_2.3.2
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
gcc-4.3.0, glibc-2.7, binutils-2.18.50.0.4
--
Summary: 'version node not found for symbol ...' during linking
against libc_pic.a
Product: binutils
Version: 2.18
Status: NEW
Severity: minor
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: pluto at agmk dot net
CC: bug-binutils at gnu dot org
GCC target triplet: x86_64-gnu-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=5905
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5905] 'version node not found for symbol ...' during linking against libc_pic.a
-- What|Removed |Added Severity|minor |normal http://sourceware.org/bugzilla/show_bug.cgi?id=5905 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5905] 'version node not found for symbol ...' during linking against libc_pic.a
-- What|Removed |Added CC||hjl dot tools at gmail dot ||com http://sourceware.org/bugzilla/show_bug.cgi?id=5905 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From ian at airs dot com 2008-03-10 17:09 --- I compiled the original test case with icc 8.1. I ran readelf -s. Here are some excerpts: 65279: 0 SECTION LOCAL DEFAULT 65278 section_65270 65280: 0 SECTION LOCAL DEFAULT 65279 section_65271 65281: 0 SECTION LOCAL DEFAULT PRC[0xff00] section_65272 65282: 0 SECTION LOCAL DEFAULT PRC[0xff01] section_65273 65283: 0 SECTION LOCAL DEFAULT PRC[0xff02] section_65274 65521: 0 SECTION LOCAL DEFAULT RSV[0xfff0] section_65512 65522: 0 SECTION LOCAL DEFAULT ABS section_65513 65523: 0 SECTION LOCAL DEFAULT COM section_65514 65524: 0 SECTION LOCAL DEFAULT RSV[0xfff3] section_65515 65536: 0 SECTION LOCAL DEFAULT RSV[0x] section_65527 65537: 0 SECTION LOCAL DEFAULT UND section_65528 65538: 0 SECTION LOCAL DEFAULT1 section_65529 65539: 0 SECTION LOCAL DEFAULT2 section_65530 135280: 4 OBJECT GLOBAL DEFAULT 65278 var_65270 135281: 4 OBJECT GLOBAL DEFAULT 65279 var_65271 135282: 4 OBJECT GLOBAL DEFAULT PRC[0xff00] var_65272 135283: 4 OBJECT GLOBAL DEFAULT PRC[0xff01] var_65273 135284: 4 OBJECT GLOBAL DEFAULT PRC[0xff02] var_65274 135522: 4 OBJECT GLOBAL DEFAULT RSV[0xfff0] var_65512 135523: 4 OBJECT GLOBAL DEFAULT ABS var_65513 135524: 4 OBJECT GLOBAL DEFAULT COM var_65514 135525: 4 OBJECT GLOBAL DEFAULT RSV[0xfff3] var_65515 135537: 4 OBJECT GLOBAL DEFAULT RSV[0x] var_65527 135538: 4 OBJECT GLOBAL DEFAULT UND var_65528 135539: 4 OBJECT GLOBAL DEFAULT1 var_65529 Then I compiled the same test case with gcc 4.2.1 and GNU binutils 2.17.50 (a snapshot). Here are some excerpts from readelf -s: 65279: 0 SECTION LOCAL DEFAULT 65278 65280: 0 SECTION LOCAL DEFAULT 65279 65281: 0 SECTION LOCAL DEFAULT 65536 65282: 0 SECTION LOCAL DEFAULT 65537 65283: 0 SECTION LOCAL DEFAULT 65538 135281: 4 OBJECT GLOBAL DEFAULT 65278 var_65275 135282: 4 OBJECT GLOBAL DEFAULT 65279 var_65276 135283: 4 OBJECT GLOBAL DEFAULT 65536 var_65277 135284: 4 OBJECT GLOBAL DEFAULT 65537 var_65278 135285: 4 OBJECT GLOBAL DEFAULT 65538 var_65279 135286: 4 OBJECT GLOBAL DEFAULT 65539 var_65280 135518: 4 OBJECT GLOBAL DEFAULT 65771 var_65512 135519: 4 OBJECT GLOBAL DEFAULT 65772 var_65513 135520: 4 OBJECT GLOBAL DEFAULT 65773 var_65514 135521: 4 OBJECT GLOBAL DEFAULT 65774 var_65515 135522: 4 OBJECT GLOBAL DEFAULT 65775 var_65516 Note that readelf is written to expect the output of gas. Note that it does not work correctly for the output of icc. icc follows the ELF ABI. gas does not. For another test, I tried the elfutils. Running eu-readelf -s on the object file generated by gcc gives me this: eu-readelf: invalid sh_link value in section 70007 In other words, the elfutils agree with icc and with the ELF ABI. They do not agree with the GNU binutils. > I think it is up for debate. I can see the point for the current BFD > behavior. That is each section index is unique, including special > ones. When I say section index 0xfff2, there is no ambiguity about > which section it refers to. If we follow the ELF ABI, each section index is still unique. The section indexes are simply the consecutive non-negative numbers up to but not including the number of sections. The values from SHN_LORESERVE to SHN_HIRESERVER are not section indexes. They are special codes which must be interpreted specially. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From ian at airs dot com 2008-03-10 17:39 --- I raised the issue on generic-abi here: http://groups.google.com/group/generic-abi/browse_frm/thread/e8bb63714b072e67 -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From hjl dot tools at gmail dot com 2008-03-10 18:09 --- gABI says: sh_link Unspecified If non-zero, the index of the section header string table section So sh_link isn't "section index", it is the section header index. What else did binutils get wrong? -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From hjl dot tools at gmail dot com 2008-03-10 18:28 --- (In reply to comment #8) > gABI says: > > sh_link Unspecified If non-zero, the index of the section header string table > section > > So sh_link isn't "section index", it is the section header index. What > else did binutils get wrong? Wait a second, the index of the section header string table section is a "section index". -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From ian at airs dot com 2008-03-10 19:04 --- Don't confuse the notion of section index with the special codes between SHN_LORESERVE and SHN_HIRESERVE. Those special codes are used in the st_shndx field of a Sym structure. They are not meaningful elsewhere--in particular they are not meaningful in the sh_link field of section header zero. The GNU binutils get that link field wrong when it needs to be larger than 0x. When the special code SHN_XINDEX is used, the ABI is explicit that the SHT_SYMTAB_SHNDX section holds the section header index. The GNU binutils store the wrong values in the SHT_SYMTAB_SHNDX section. I don't know of anything else that the GNU binutils get wrong. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From hjl dot tools at gmail dot com 2008-03-10 19:14 --- gABI says: Some section header table indexes are reserved in contexts where index size is restricted, for example, the st_shndx member of a symbol table entry and the e_shnum and e_shstrndx members of the ELF header. In such contexts, the reserved values do not represent actual sections in the object file. Also in such contexts, an escape value indicates that the actual section index is to be found elsewhere, in a larger field. That means we can't use from SHN_UNDEF and SHN_LORESERVE to SHN_HIRESERVE anywhere else. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From ian at airs dot com 2008-03-10 20:03 --- > That means we can't use from SHN_UNDEF and SHN_LORESERVE to SHN_HIRESERVE > anywhere else. No, it doesn't. It only means that you can't use them in contexts "where index size is restricted." -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From hjl dot tools at gmail dot com 2008-03-10 20:43 --- (In reply to comment #12) > > That means we can't use from SHN_UNDEF and SHN_LORESERVE to SHN_HIRESERVE > > anywhere else. > > No, it doesn't. It only means that you can't use them in contexts "where > index > size is restricted." > It isn't clear to me if those special values have special means where the index size isn't restricted. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From ian at airs dot com 2008-03-10 21:25 --- I don't see anything in the ABI which says they have special meanings. And I certainly don't see anything in the ABI which says that code should add 256 to section indexes when stored. I think it would be important to not omit a statement like that, as otherwise anybody could invent whatever procedure they liked to avoid the special values. And, again, the ABI works without adding 256. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5900] ELF files with more than 65536 sections not handled correctly.
--- Additional Comments From amodra at bigpond dot net dot au 2008-03-11 00:49 --- I am to blame, and can't find anything to defend the current binutils behaviour. i.e. I agree with Ian that this is a bug. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
