Re: RFA: Support for Thumb in dynamic objects

[Ian Lance Taylor <ian@wasabisystems.com>]

Daniel Jacobowitz <drow@false.org> writes:

> This patch adds limited support for Thumb in dynamic objects.  It causes the
> glue stubs not to be exported from the object, and uses a prefix to the PLT
> entry to change mode instead of a glue stub off somewhere else.  It also
> fixes objdump to display thumb functions using the STT_ARM_TFUNC type as
> functions.
> 
> It's easy to stop using STT_ARM_TFUNC and start using an odd symbol value
> for dynamic objects; but I didn't want to mix it with this patch.  So that's
> a TODO.  Other TODOs are:
>   - some kind of mappng symbols in the .plt section so that the disassembler
>     knows what to do (we can't easily generate new local symbols from the
>     backend, but I'm sure there's a way around it); this is very important
>     for GDB.
>   - Related, synthetic named symbols for the .plt as implemented for other
>     architectures.
>   - BLX support.  The only reason I didn't do this is that there's no easy
>     way to tell if using BLX is OK; i.e. whether we can assume the presence
>     of ARM v5t.
> 
> OK?  Comments?

My main comment is that I've done similar work, but I had the luxury
of simply assuming ARMv5t.  You can do so much better in that case
that I do think we need to let the linker make that assumption when
possible.  The easy way to do it automatically would be to say that if
any input .o file is marked for a processor supporting ARMv5t or
above, we can assume that the output will be too, and we can use
ARMv5t in the PLT support, etc.

There is, of course, a second related issue, which is whether the
other objects involved in the dynamic link are compiled with
interworking support.  In my case I could not assume that.  So while
my linker doesn't add a stub for each R_ARM_THM_PC22 reloc--it just
changes those to blx when appropriate--it does automatically add a
stub for ABS32 and GOT32 references to Thumb code.  I don't have a
good automatic solution here--perhaps the new new ABI, which I gather
requires interworking support, will take the issue off the table.

Along similar lines it is quite easy for the linker to generate stubs
for all functions potentially referenced by non-interworking code, so
the need for the -mcallee-super-interworking option goes away.

Ian