This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, arm] Thumb shared library support: Thumb PLT, etc.
- From: Adam Nemet <anemet at Lnxw dot COM>
- To: Richard dot Earnshaw at arm dot com
- Cc: binutils at sources dot redhat dot com
- Date: 18 Jul 2002 11:47:31 -0700
- Subject: Re: [PATCH, arm] Thumb shared library support: Thumb PLT, etc.
- References: <200207181010.LAA14230@cam-mail2.cambridge.arm.com>
> First of all, do you have a copyright assignment in place for binutils
> (and gcc, for your other patch)? Until that's sorted out we can't use
> your code.
Yes, I have assingment papers on file for GCC and binutils.
> 1) I don't like the idea of having some special flag (--thumb-plt) that
> indicates that we should build a different type of PLT. The linker must
> be able to figure this out automatically, or we will end up with major
> problems when it comes to interworking.
First of all these were my design principals while implementing this:
1. Making Thumb shared libraries work should _not_ effect ARM shared
libraries. People who want to make their code smaller are more
likely to have the time to ``manually'' fine-tune their application
than those who don't care and just want something to work on ARM.
2. Interworking issues should be kept separately. I'd like to be able
to build pure ARM and pure Thumb shared libraries without compiling
them with --mthumb-interwork.
> We need more space for the thumb sequence than we do for an ARM one. That
> suggests that we should probably be looking to switch to ARM code for the
> stub. For example, we could use
> .code 16
> .align 2
> bx pc
> .code 32
> ldr ip, [pc, #8]
> add ip, pc, ip
> ldr ip, [ip]
> bx ip
> .word offset_to_target
> which means we can share the stub with both ARM and Thumb code. So while
> this is now 6 words long we save on duplication, and we have interworking
> from the start.
I was playing with the same idea originally but I didn't like it
* It does not fit well with principle #1 above. 6 instead of 4
words in the ARM case and 6 instead of 5 words for Thumb. ARM PLT
will be 50% bigger.
* It won't work. Upon calling plt with lazy relocation, ip has
to hold &GOT[n+3] so that ld.so can figure which GOT entry it
needs to relocate. See sysdeps/arm/dl-machine.h in glibc for an
* In addition, what is the cost of switching mode twice for a pure
thumb shared library call every time we call it?
* What if a Thumb function in the library wants to return with mov
pc, lr. I know that GCC does not generate such a sequence but it
is still valid and contradicts principal #2.
Bottom line, I don't think we should favor Thumb or interwork over ARM
or some complication in the linker. Pure ARM should be as fast as
possible. In fact the reason why we need an explicit switch to
generate a PLT that can handle Thumb is pretty much the same why
--mthumb-interwork is not the default behavior in the GCC backend: it
is not free.