Re: Long call support broke Thumb veneers

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

> > My initial need is only to support R_ARM_CALL and R_ARM_THM_CALL  
> > relocations (we use only EABI).
> > I also considered changing the code handling the relocs you mention, but  
> > as I would be unable to test it properly I prefered not to change it.
>
> R_ARM_JUMP24 is also an EABI relocation, used for tail calls.
OK. As we never came up with truncated relocs in this case, it's not a 
priority for us to support it. I will try to spend some time on this though.

> By tables, I mean e.g. the ARM vector table (which contains
> branches).  If it's built up by more than one section, we're going to
> throw branch stubs in the middle of it - not cool.  Something like this:
>
>   *(.text.header.reset-vector)
>   *(.text.header.unaligned-vector)
>   *(.text.header.interrupt-vector)
>
> Does that make more sense?
Yes. Now I understand better your point.

> > What about grouping your cs3 regions like this:
>
> I don't understand.  Why would this help?  You've broken the one
> output section into two, but I believe we create stubs in front of
> input sections, not in front of output sections.

Input sections are grouped (for stubs purpose) by output section first, 
then these groups are split according to size criteria.
If you break output sections, you also end up with different stub sections.
And provided your first output section does not cause stubs to be 
generated, you avoid the problem.

> I've still got concerns about the implementation, but this is clearly
> an improvement.  It's OK; I'll check it in for you, but you may want
> to request a sourceware account.

Thank you.

Christophe.