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