* Abort in elflink.c: elf_link_check_versioned_symbol @ 2009-08-26 11:31 Ramana Radhakrishnan 2009-08-26 13:17 ` Ramana Radhakrishnan 2009-08-26 19:04 ` Ian Lance Taylor 0 siblings, 2 replies; 7+ messages in thread From: Ramana Radhakrishnan @ 2009-08-26 11:31 UTC (permalink / raw) To: binutils Hi, I've been looking at a linker abort in elflink.c:elf_link_check_versioned_symbol as a part of a larger project that a coworker is doing on an arm-linux-gnueabi platform. I haven't yet constructed a smaller testcase but I am looking at a bit of code that doesn't look correct to me. This bit of code is the bit that aborts in elflink.c:elf_link_check_versioned_symbol . if ((iver.vs_vers & VERSYM_HIDDEN) == 0) { /* If we have a non-hidden versioned sym, then it should have provided a definition for the undefined sym. */ abort (); } The symbol for which this abort happens is _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc ++.so. Looking at this symbol in libstdc++.so, I can see that this is versioned and weak as below but the actual symbol doesn't appear in the shared object. From the Symbol Table of libstdc++ 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 From the Version Table of libstdc++ 3a8: 2 (GLIBCXX_3.4) 2 (GLIBCXX_3.4) 2 (GLIBCXX_3.4) 2 (GLIBCXX_3.4) There is a reference to this file in foo.o compiled with fPIC present in a library lib.a which is in the final link. 00005950 0003d51b R_ARM_PLT32 00000000 _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE Shouldn't this be an error condition for an undefined symbol instead of an abort as here ? While fixing this will not fix the underlying problem my colleague faces, surely the linker should at this point give an error for an undefined reference and bail out gracefully rather than aborting. cheers Ramana ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Abort in elflink.c: elf_link_check_versioned_symbol 2009-08-26 11:31 Abort in elflink.c: elf_link_check_versioned_symbol Ramana Radhakrishnan @ 2009-08-26 13:17 ` Ramana Radhakrishnan 2009-08-26 19:04 ` Ian Lance Taylor 1 sibling, 0 replies; 7+ messages in thread From: Ramana Radhakrishnan @ 2009-08-26 13:17 UTC (permalink / raw) To: binutils On Wed, 2009-08-26 at 11:10 +0100, Ramana Radhakrishnan wrote: > > > Shouldn't this be an error condition for an undefined symbol instead > of > an abort as here ? While fixing this will not fix the underlying > problem my colleague faces, surely the linker should at this point > give > an error for an undefined reference and bail out gracefully rather > than > aborting. When I say this, I assume that the actual interface also needs to be defined along with the versioned symbol in the symbol table i.e you need sym and sym@@VERS defined in the symbol table. If OTOH this isn't the case , then the abort appears wrong to me and removing the abort builds the application for me . I'm not sure about the correct fix here and haven't looked at symbol versioning issues before, so some advice from folks more knowledgeable about why the assert is there in the first place would be useful to understand. cheers Ramana ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Abort in elflink.c: elf_link_check_versioned_symbol 2009-08-26 11:31 Abort in elflink.c: elf_link_check_versioned_symbol Ramana Radhakrishnan 2009-08-26 13:17 ` Ramana Radhakrishnan @ 2009-08-26 19:04 ` Ian Lance Taylor 2009-09-02 12:49 ` Ramana Radhakrishnan 1 sibling, 1 reply; 7+ messages in thread From: Ian Lance Taylor @ 2009-08-26 19:04 UTC (permalink / raw) To: ramana.radhakrishnan; +Cc: binutils Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes: > The symbol for which this abort happens is > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc > ++.so. Looking at this symbol in libstdc++.so, I can see that this is > versioned and weak as below but the actual symbol doesn't appear in the > shared object. > >From the Symbol Table of libstdc++ > > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 That is a real symbol definition. It merely happens to be marked weak. I think what is happening is that elf_link_check_versioned_symbol assumes that it will only be called when the regular symbol resolution code did not resolve the symbol. So it does not expect to see an unhidden symbol here; an unhidden symbol should already have been resolved. So you should find out why elf_link_check_versioned_symbol is being called here. Ian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Abort in elflink.c: elf_link_check_versioned_symbol 2009-08-26 19:04 ` Ian Lance Taylor @ 2009-09-02 12:49 ` Ramana Radhakrishnan 2009-09-02 16:28 ` Ian Lance Taylor 2009-09-02 16:37 ` H.J. Lu 0 siblings, 2 replies; 7+ messages in thread From: Ramana Radhakrishnan @ 2009-09-02 12:49 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils Hi Ian, Thanks for your email and apologies for the late response. On Wed, 2009-08-26 at 07:59 -0700, Ian Lance Taylor wrote: > Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes: > > > The symbol for which this abort happens is > > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc > > ++.so. Looking at this symbol in libstdc++.so, I can see that this is > > versioned and weak as below but the actual symbol doesn't appear in the > > shared object. > > > >>From the Symbol Table of libstdc++ > > > > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 > > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 > > That is a real symbol definition. It merely happens to be marked weak. Fair enough. If this is a real symbol definition and happens to be just marked weak , then shouldn't all references resolve to this symbol. > > I think what is happening is that elf_link_check_versioned_symbol > assumes that it will only be called when the regular symbol resolution > code did not resolve the symbol. So it does not expect to see an > unhidden symbol here; an unhidden symbol should already have been > resolved. So you should find out why elf_link_check_versioned_symbol is > being called here. elf_link_check_versioned_symbol is being called from the following call stack Breakpoint 1, _bfd_abort (file=0xe2c18 "/home/ramrad01/sources/src/bfd/elflink.c", line=8440, fn=0xe36f0 "elf_link_check_versioned_symbol") at /home/ramrad01/sources/src/bfd/bfd.c:928 928 { (gdb) bt #0 _bfd_abort (file=0xe2c18 "/home/ramrad01/sources/src/bfd/elflink.c", line=8440, fn=0xe36f0 "elf_link_check_versioned_symbol") at /home/ramrad01/sources/src/bfd/bfd.c:928 #1 0x00068474 in elf_link_check_versioned_symbol (info=<value optimized out>, bed=0xbeffca84, h=0x1a405e0) at /home/ramrad01/sources/src/bfd/elflink.c:8440 #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data=<value optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 #3 0x00039308 in bfd_hash_traverse (table=0x110578, func=0x68484 <elf_link_output_extsym>, info=0xbeffca84) at /home/ramrad01/sources/src/bfd/hash.c:603 #4 0x0006f114 in bfd_elf_final_link (abfd=0x16b18, info=0x845a8) at /home/ramrad01/sources/src/bfd/elflink.c:10588 #5 0x0004a99c in elf32_arm_final_link (abfd=0xe2c18, info=0x20f8) at /home/ramrad01/sources/src/bfd/elf32-arm.c:9296 #6 0x0001ea1c in ldwrite () at /home/ramrad01/sources/src/ld/ldwrite.c:567 #7 0x0001de58 in main (argc=0, argv=0x9984) at /home/ramrad01/sources/src/ld/ldmain.c:464 (gdb) up #1 0x00068474 in elf_link_check_versioned_symbol (info=<value optimized out>, bed=0xbeffca84, h=0x1a405e0) at /home/ramrad01/sources/src/bfd/elflink.c:8440 8440 abort (); (gdb) up #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data=<value optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 8531 if (! finfo->info->relocatable As you can see this is getting called from bfd_elf_final_link which ends up calling elf_link_output_extsym where the abort happens. The reason that we call this in elf_link_output_extsym from the following comment is - (gdb) l 8536 8531 if (! finfo->info->relocatable 8532 && (! finfo->info->shared) 8533 && h->forced_local 8534 && h->ref_dynamic 8535 && !h->dynamic_def 8536 && !h->dynamic_weak 8537 && ! elf_link_check_versioned_symbol (finfo->info, bed, h)) 8538 { 8539 (*_bfd_error_handler) 8540 (_("%B: %s symbol `%s' in %B is referenced by DSO"), which appears to be correct. From what you say and looking at the code it appears as though one might have to refactor the code accordingly - to give errors depending on when this function is called ? cheers Ramana ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Abort in elflink.c: elf_link_check_versioned_symbol 2009-09-02 12:49 ` Ramana Radhakrishnan @ 2009-09-02 16:28 ` Ian Lance Taylor 2009-09-03 11:15 ` Ramana Radhakrishnan 2009-09-02 16:37 ` H.J. Lu 1 sibling, 1 reply; 7+ messages in thread From: Ian Lance Taylor @ 2009-09-02 16:28 UTC (permalink / raw) To: ramana.radhakrishnan; +Cc: binutils Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes: >> > The symbol for which this abort happens is >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc >> > ++.so. Looking at this symbol in libstdc++.so, I can see that this is >> > versioned and weak as below but the actual symbol doesn't appear in the >> > shared object. >> > >> >>From the Symbol Table of libstdc++ >> > >> > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 >> >> That is a real symbol definition. It merely happens to be marked weak. > > Fair enough. If this is a real symbol definition and happens to be just > marked weak , then shouldn't all references resolve to this symbol. Normally yes, but based on the code path you show below the symbol has been forced to be local. That is, you are using a version script which forces this symbol to be local and therefore not visible to shared libraries. >> I think what is happening is that elf_link_check_versioned_symbol >> assumes that it will only be called when the regular symbol resolution >> code did not resolve the symbol. So it does not expect to see an >> unhidden symbol here; an unhidden symbol should already have been >> resolved. So you should find out why elf_link_check_versioned_symbol is >> being called here. > > elf_link_check_versioned_symbol is being called from the following call > stack > > Breakpoint 1, _bfd_abort (file=0xe2c18 > "/home/ramrad01/sources/src/bfd/elflink.c", line=8440, fn=0xe36f0 > "elf_link_check_versioned_symbol") > at /home/ramrad01/sources/src/bfd/bfd.c:928 > 928 { > (gdb) bt > #0 _bfd_abort (file=0xe2c18 "/home/ramrad01/sources/src/bfd/elflink.c", > line=8440, fn=0xe36f0 "elf_link_check_versioned_symbol") > at /home/ramrad01/sources/src/bfd/bfd.c:928 > #1 0x00068474 in elf_link_check_versioned_symbol (info=<value optimized > out>, bed=0xbeffca84, h=0x1a405e0) > at /home/ramrad01/sources/src/bfd/elflink.c:8440 > #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data=<value > optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 > #3 0x00039308 in bfd_hash_traverse (table=0x110578, func=0x68484 > <elf_link_output_extsym>, info=0xbeffca84) > at /home/ramrad01/sources/src/bfd/hash.c:603 > #4 0x0006f114 in bfd_elf_final_link (abfd=0x16b18, info=0x845a8) > at /home/ramrad01/sources/src/bfd/elflink.c:10588 > #5 0x0004a99c in elf32_arm_final_link (abfd=0xe2c18, info=0x20f8) > at /home/ramrad01/sources/src/bfd/elf32-arm.c:9296 > #6 0x0001ea1c in ldwrite () > at /home/ramrad01/sources/src/ld/ldwrite.c:567 > #7 0x0001de58 in main (argc=0, argv=0x9984) > at /home/ramrad01/sources/src/ld/ldmain.c:464 > (gdb) up > #1 0x00068474 in elf_link_check_versioned_symbol (info=<value optimized > out>, bed=0xbeffca84, h=0x1a405e0) > at /home/ramrad01/sources/src/bfd/elflink.c:8440 > 8440 abort (); > (gdb) up > #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data=<value > optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 > 8531 if (! finfo->info->relocatable > > > As you can see this is getting called from bfd_elf_final_link which ends > up calling elf_link_output_extsym where the abort happens. > > The reason that we call this in elf_link_output_extsym from the > following comment is - > > (gdb) l 8536 > 8531 if (! finfo->info->relocatable > 8532 && (! finfo->info->shared) > 8533 && h->forced_local > 8534 && h->ref_dynamic > 8535 && !h->dynamic_def > 8536 && !h->dynamic_weak > 8537 && ! elf_link_check_versioned_symbol (finfo->info, bed, > h)) > 8538 { > 8539 (*_bfd_error_handler) > 8540 (_("%B: %s symbol `%s' in %B is referenced by DSO"), > > > which appears to be correct. From what you say and looking at the code > it appears as though one might have to refactor the code accordingly - > to give errors depending on when this function is called ? I think this case in elf_link_check_versioned_symbol: if ((iver.vs_vers & VERSYM_HIDDEN) == 0) { /* If we have a non-hidden versioned sym, then it should have provided a definition for the undefined sym. */ abort (); } should simply return FALSE. You've demonstrated that this case can arise when a version script is used. Ian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Abort in elflink.c: elf_link_check_versioned_symbol 2009-09-02 16:28 ` Ian Lance Taylor @ 2009-09-03 11:15 ` Ramana Radhakrishnan 0 siblings, 0 replies; 7+ messages in thread From: Ramana Radhakrishnan @ 2009-09-03 11:15 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils On Wed, 2009-09-02 at 09:28 -0700, Ian Lance Taylor wrote: > Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes: > > >> > The symbol for which this abort happens is > >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc > >> > ++.so. Looking at this symbol in libstdc++.so, I can see that this is > >> > versioned and weak as below but the actual symbol doesn't appear in the > >> > shared object. > >> > > >> >>From the Symbol Table of libstdc++ > >> > > >> > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 > >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 > >> > >> That is a real symbol definition. It merely happens to be marked weak. > > > > Fair enough. If this is a real symbol definition and happens to be just > > marked weak , then shouldn't all references resolve to this symbol. > > Normally yes, but based on the code path you show below the symbol has > been forced to be local. That is, you are using a version script which > forces this symbol to be local and therefore not visible to shared > libraries. Thanks for looking at this. I'm not clear what the behaviour here should be - If this symbol is defined in libstdc++.so and none of the object files / archive files being linked in override it, why should it be marked as local (inspite of the version script telling it to do so ) ? My understanding was that local:* in a version script would apply to all the symbols in the object files that were being linked in and not the symbols defined in the shared libraries. Is that correct ? > should simply return FALSE. You've demonstrated that this case can > arise when a version script is used. Simply returning a FALSE here causes a linker error message /home/ramrad01/install-arm-binutils-trunk/bin/ld: gamma: local symbol `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<char> const&)' in libs/libLLVMSupport.a(CommandLine.o) is referenced by DSO /home/ramrad01/install-arm-binutils-trunk/bin/ld: final link failed: Nonrepresentable section on output I'm working on getting a smaller testcase yet cheers Ramana ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Abort in elflink.c: elf_link_check_versioned_symbol 2009-09-02 12:49 ` Ramana Radhakrishnan 2009-09-02 16:28 ` Ian Lance Taylor @ 2009-09-02 16:37 ` H.J. Lu 1 sibling, 0 replies; 7+ messages in thread From: H.J. Lu @ 2009-09-02 16:37 UTC (permalink / raw) To: ramana.radhakrishnan; +Cc: Ian Lance Taylor, binutils On Wed, Sep 2, 2009 at 5:49 AM, Ramana Radhakrishnan<ramana.radhakrishnan@arm.com> wrote: > Hi Ian, > > Thanks for your email and apologies for the late response. > > On Wed, 2009-08-26 at 07:59 -0700, Ian Lance Taylor wrote: >> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> writes: >> >> > The symbol for which this abort happens is >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE from libstdc >> > ++.so. Looking at this symbol in libstdc++.so, I can see that this is >> > versioned and weak as below but the actual symbol doesn't appear in the >> > shared object. >> > >> >>From the Symbol Table of libstdc++ >> > >> > 936: 0008e1e4 40 FUNC WEAK DEFAULT 11 >> > _ZNSsC1IN9__gnu_cxx17__normal_iteratorIPcSsEEEET_S4_RKSaIcE@@GLIBCXX_3.4 >> >> That is a real symbol definition. It merely happens to be marked weak. > > Fair enough. If this is a real symbol definition and happens to be just > marked weak , then shouldn't all references resolve to this symbol. > >> >> I think what is happening is that elf_link_check_versioned_symbol >> assumes that it will only be called when the regular symbol resolution >> code did not resolve the symbol. So it does not expect to see an >> unhidden symbol here; an unhidden symbol should already have been >> resolved. So you should find out why elf_link_check_versioned_symbol is >> being called here. > > elf_link_check_versioned_symbol is being called from the following call > stack > > Breakpoint 1, _bfd_abort (file=0xe2c18 > "/home/ramrad01/sources/src/bfd/elflink.c", line=8440, fn=0xe36f0 > "elf_link_check_versioned_symbol") > at /home/ramrad01/sources/src/bfd/bfd.c:928 > 928 { > (gdb) bt > #0 _bfd_abort (file=0xe2c18 "/home/ramrad01/sources/src/bfd/elflink.c", > line=8440, fn=0xe36f0 "elf_link_check_versioned_symbol") > at /home/ramrad01/sources/src/bfd/bfd.c:928 > #1 0x00068474 in elf_link_check_versioned_symbol (info=<value optimized > out>, bed=0xbeffca84, h=0x1a405e0) > at /home/ramrad01/sources/src/bfd/elflink.c:8440 > #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data=<value > optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 > #3 0x00039308 in bfd_hash_traverse (table=0x110578, func=0x68484 > <elf_link_output_extsym>, info=0xbeffca84) > at /home/ramrad01/sources/src/bfd/hash.c:603 > #4 0x0006f114 in bfd_elf_final_link (abfd=0x16b18, info=0x845a8) > at /home/ramrad01/sources/src/bfd/elflink.c:10588 > #5 0x0004a99c in elf32_arm_final_link (abfd=0xe2c18, info=0x20f8) > at /home/ramrad01/sources/src/bfd/elf32-arm.c:9296 > #6 0x0001ea1c in ldwrite () > at /home/ramrad01/sources/src/ld/ldwrite.c:567 > #7 0x0001de58 in main (argc=0, argv=0x9984) > at /home/ramrad01/sources/src/ld/ldmain.c:464 > (gdb) up > #1 0x00068474 in elf_link_check_versioned_symbol (info=<value optimized > out>, bed=0xbeffca84, h=0x1a405e0) > at /home/ramrad01/sources/src/bfd/elflink.c:8440 > 8440 abort (); > (gdb) up > #2 0x00068a4c in elf_link_output_extsym (h=0x1a405e0, data=<value > optimized out>) at /home/ramrad01/sources/src/bfd/elflink.c:8531 > 8531 if (! finfo->info->relocatable > > > As you can see this is getting called from bfd_elf_final_link which ends > up calling elf_link_output_extsym where the abort happens. > > The reason that we call this in elf_link_output_extsym from the > following comment is - > > (gdb) l 8536 > 8531 if (! finfo->info->relocatable > 8532 && (! finfo->info->shared) > 8533 && h->forced_local > 8534 && h->ref_dynamic > 8535 && !h->dynamic_def > 8536 && !h->dynamic_weak > 8537 && ! elf_link_check_versioned_symbol (finfo->info, bed, > h)) > 8538 { > 8539 (*_bfd_error_handler) > 8540 (_("%B: %s symbol `%s' in %B is referenced by DSO"), > > > which appears to be correct. From what you say and looking at the code > it appears as though one might have to refactor the code accordingly - > to give errors depending on when this function is called ? > > It is quite strange. If you can provide a testcase which I can reproduce with a cross linker, I will take a look. Thanks. -- H.J. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-09-03 11:15 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-08-26 11:31 Abort in elflink.c: elf_link_check_versioned_symbol Ramana Radhakrishnan 2009-08-26 13:17 ` Ramana Radhakrishnan 2009-08-26 19:04 ` Ian Lance Taylor 2009-09-02 12:49 ` Ramana Radhakrishnan 2009-09-02 16:28 ` Ian Lance Taylor 2009-09-03 11:15 ` Ramana Radhakrishnan 2009-09-02 16:37 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).