Re: [PATCH, arm] Thumb shared library support: Thumb PLT, etc.

[Adam Nemet <anemet at Lnxw dot COM>]

> All it requires is for the linker to track a bit more information
> when pushing an internal PLT data structure onto the list of things
> to generate.

As long as we can make sure that neither pure ARM nor pure Thumb get
punished because of this generalization, I am fine with this and I am
ready to change my patch to cover interworking as well.

BTW, what do you think about the fini/init parts.  Are they
acceptable?  And what about the GCC patch?

> Since we know whether that was an ARM or a Thumb type relocation we
> can generate the correct PLT entry without the need to have a
> command line switch.

I think instead of the relocation type, we should rather look at the
the type of the function (STT_FUNC or STT_ARM_TFUNC) we are relocating
against.  I believe the logic is cleaner if we just consider the PLT
as an extension of the shared library and as such it should match the
type of the function it calls into.  (In case of STT_NOTYPE, we should
probably assume that the callee matches the caller.)  Of course on the
caller side between the caller and the PLT entry, we might need to
emit stubs for mode switching the usual way.

In your solution if we were to match the instruction set of the
caller, if the same PLT entry is referred from a Thumb and an ARM
function we have no way to decide which type of PLT entry we need to
generate whereas if it matches the callee it is always obvious.

I would also prefer to have separate plt for the Thumb entries e.g.
.plt.thumb or something like that so that disassembling the plt would
be as simple as:

  objdump -d -j.plt a.out
  objdump -d -j.plt.thumb --disassembler-option=force-thumb a.out

Also note that the Thumb and the ARM PLT entries are of different size
(5 words and 4 words) so finding the offset to one entry is easier if
we keep them separately.

I also plan to issue a warning is someone is trying to mix
instrunction sets between the caller and the callee without having the
interworking flag set in the ELF header.  This is a good indicator
that the user doesn't want the interwork overhead but just accidently
used the wrong version of the library.  This is pretty much a natural
extension of the existing warning message when one wants to intermix
different non-interworking object files.

If we agree on these details I will go and try to extend how PLT is
handled currently so that it can provide the functionality for mixing
the two types of PLT entries.

Adam