This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFA: Support for Thumb in dynamic objects
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