Re: ARM long branch stubs: shared libs

[Christophe LYON <christophe dot lyon at st dot com>]

> > +		      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.