Abort in elflink.c: elf_link_check_versioned_symbol

Abort in elflink.c: elf_link_check_versioned_symbol

[Ramana Radhakrishnan]

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

Re: Abort in elflink.c: elf_link_check_versioned_symbol

[Ramana Radhakrishnan]

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

Re: Abort in elflink.c: elf_link_check_versioned_symbol

[Ian Lance Taylor]

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

Re: Abort in elflink.c: elf_link_check_versioned_symbol

[Ramana Radhakrishnan]

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

Re: Abort in elflink.c: elf_link_check_versioned_symbol

[Ian Lance Taylor]

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

Re: Abort in elflink.c: elf_link_check_versioned_symbol

[H.J. Lu]

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.

Re: Abort in elflink.c: elf_link_check_versioned_symbol

[Ramana Radhakrishnan]

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