Re: RFA: Support for Thumb in dynamic objects

[Daniel Jacobowitz <drow@false.org>]

On Tue, Nov 16, 2004 at 08:37:31PM -0500, Ian Lance Taylor wrote:
> 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.

That's what I've done in the past - a previous version of this patch
used this to select v4t interworking capable PLT entries.

But - none of that is EABI compliant.  I don't know whether the EABI
has got anything to say on this subject yet; I know it was discussed.
But the way the GNU tools use ELF header flags is noncompliant, so I've
been trying not to introduce more uses.

So I just punted on the issue.

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

I haven't done any work on the linker equivalents of super
interworking, since I didn't need them at the time.  If you'd like to
contribute it, of course... :-)

-- 
Daniel Jacobowitz