Re: [arm] EABI annotation of thumb symbols.

[Richard Earnshaw <rearnsha at arm dot com>]

On Thu, 2004-11-04 at 15:03, Ian Lance Taylor wrote:
> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> > Don't do Thumb PLT's.  The idea doesn't work.
> > 
> >         1) You don't know whether the target will be ARM or Thumb (it's
> >         in another shared library which may not be the same at run time
> >         as the one you link against at static link time -- don't forget
> >         pre-emption).  So the sequence has to end with an instruction
> >         that can change instruction set state (on v4T that means bx).
> >         
> >         2) You don't have enough registers to do a bx at the end of the
> >         sequence and remember where you've come from (Needed for
> >         re-entry into the dynamic linker, especially if you want to
> >         continue to support pre-linking).  To avoid this you end up
> >         playing games that make the sequence as long as any ARM
> >         equivalent -- and there are still problems.
> 
> I certainly agree that Thumb PLTs are only useful on v5t and up.  For
> my purposes, that is OK, since our customers use XScale chips.
> 
> That said, I'm building Thumb shared libraries in which the PLT takes
> up 120K, or some 4.5% of the text section size.  It's probably
> possible to use version scripts to force some of the symbols to be
> local, but this source code is neither from us nor from our customer,
> so that is not a simple task.  Using Thumb instructions in the PLT
> would give me some clearly measurable size improvements.

Ultimately it depends on the performance you want out of your code.  If
performance is not a goal at all, then you could probably squeeze each
PLT stub down to about 4 bytes, with

	mov	ip, pc
	b	common_plt

(and if the plt cannot reach common_plt, then chain it to one that
can).  common_plt can do all manner of things, provided that at the
point at which it calls into the target function things are set up
correctly in case we end up in the dynamic linker.  But remember that
the sequence above depends critically on each PLT sequence being the
same length and on them all being located sequentially in memory (so
that the PC value can be converted algorithmically into a PLTGOT value).

The critical thing about PLT stubs is not the code that you execute in
them as much as the values in registers if you end up entering the
dynamic linker.  There a number of constraints there, especially if we
want to maintain some semblance of compatibility with existing code.

So, the ABI does not lay down what a PLT sequence must be.  It does,
however, lay down the constraints that such a sequence must meet in
order to permit dynamic linking (if you do all your linking off-line, or
don't want to permit lazy binding then some of those constraints can be
lifted as well).  In particular, IP must point at the PLTGOT slot so
that the dynamic linker can patch the correct place.

R.