ARM long branch stubs: shared libs

Christophe LYON christophe.lyon@st.com
Thu Apr 2 15:06:00 GMT 2009


>> +		      else if (hash->root.root.type == bfd_link_hash_undefweak)
>>  			/* For a shared library, these will need a PLT stub,
>>  			   which is treated separately.
>>  			   For absolute code, they cannot be handled.  */
>>  			continue;
>> +		      else if (hash->root.root.type == bfd_link_hash_undefined)
>> +			{
> 
> Why should undefined and weak undefined symbols be handled
> differently?  That's usually a mistake.  Take your test case for this
> issue and mark the undefined symbol with ".weak".
> 

Because I didn't want to change a behaviour I didn't completely master. 
As the usual rule applies: what is not tested does not work.

But... I have tried your suggestion (ie. mark the undef symbol with 
.weak in the testcase), and I get an error message from the linker 
(relocation truncated to fit).

Now, if I handle undefweak and undef symbols in the same way, I observed 
that:
- in allocate_dynrelocs, a PLT entry is created for the undefweak, 
despite the comment "Make sure this symbol is output as a dynamic 
symbol. Undefined weak syms won't yet be marked as dynamic."
- then, the reference from ARM code is turned into a jump to the next 
instruction
- but references from THUMB code aren't. There is a comment saying "A 
branch to an undefined weak symbol is turned into a jump to the next 
instruction unless a PLT entry will be created"

Why is there a different handling of a ARM call vs a THUMB call in this 
case?

Thanks,

Christophe.



More information about the Binutils mailing list