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

[Adam Nemet <anemet at Lnxw dot COM>]

Richard,

> 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
> _plt_stub_thumb:
> 	bx	pc
> 	nop
> 	.code 32
> _plt_stub_arm:
> 	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
because:
  Major issues:

  * 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[0] 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
    example.

  Minor issues:

  * 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.

Adam