This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [arm] EABI annotation of thumb symbols.

On Thu, Nov 04, 2004 at 10:20:44AM +0000, Richard Earnshaw wrote:
> On Thu, 2004-11-04 at 01:54, Ian Lance Taylor wrote:
> > Daniel Jacobowitz <> writes:
> > 
> > > [This was one of the last open issues I had questions about before
> > > posting the Thumb PLT patches I've mentioned before.  I will try to do
> > > that Really, Really Soon, like this afternoon.]
> > 
> > I was thinking about Thumb PLT earlier.  I can see how to get each PLT
> > entry down to 8 bytes, but the linker would have to strew various
> > branches across the PLT to get around the limited range of the Thumb
> > branch instruction.  Is that the type of thing you are doing?
> Don't do Thumb PLT's.  The idea doesn't work.

Yes.  Sorry I was unclear; I meant "PLTs usable from Thumb".  It could
be done somewhat more efficiently than the way I did it for v5 (by
editing branches in the input), but I just put Thumb-to-ARM stubs in
the right place.  Once the OABI code has been dealt with I'll post it,

>         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.
> We concluded that the best solution on v4T chips was to insist that all
> shared library functions were entered in ARM state (they can switch back
> to Thumb internally); it the linker's job to create the proper entry
> points when building a shared library.  In libraries that will run on v5
> or later systems, the restriction can be lifted, since an ldr to the PC
> can switch to Thumb state without problems.

I've actually implemented the alternative suggested in a document
someone (you?  Phil?) posted to the EABI list at some point, in which
GOT entries point back into the proper PLT stub.  This supports
entering shared libraries in Thumb mode on V4T.  However, I'm quite
willing to ditch that part of the patch, and try to implement
generating ARM entry points instead.

Daniel Jacobowitz

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]