This is the mail archive of the
mailing list for the binutils project.
Re: RFA: Support for Thumb in dynamic objects
- From: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 17 Nov 2004 13:48:06 +0000
- Subject: Re: RFA: Support for Thumb in dynamic objects
- Organization: GNU
- References: <20041116233909.GA31434@nevyn.them.org>
On Tue, 2004-11-16 at 23:39, Daniel Jacobowitz wrote:
> 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
> 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.
This is also essential for BE-8 support. Without it we can't byte-swap
correctly (though if byte-swapping were to be integrated into the linker
it could be fudged some other way).
> - Related, synthetic named symbols for the .plt as implemented for other
> - 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.
Not withstanding the need to invent some suitable way of describing the
input object files, ld needs to start handling the -mcpu and -march
flags that we currently pass to the compiler and the linker. There are
times when building objects that can run on multiple ARM machines where
we can't safely determine that because one object file uses (for
example) v5t, that it is safe to use v5t instructions everywhere.
> OK? Comments?
This is OK once you've addressed the point Paul raised. You might also
have to look at the tests when run in big-endian mode too.