This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Detect ARM MOVW/MOVT relocations in shared library links
- From: Daniel Jacobowitz <drow at false dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: binutils at sourceware dot org
- Date: Wed, 29 Apr 2009 16:59:23 -0400
- Subject: Re: Detect ARM MOVW/MOVT relocations in shared library links
- References: <Pine.LNX.4.64.0904272205550.11753@digraph.polyomino.org.uk>
On Mon, Apr 27, 2009 at 10:06:39PM +0000, Joseph S. Myers wrote:
> ARMv7 has MOVW and MOVT instructions for loading constants without
> needing a constant pool, and associated relocations for when those
> constants are symbol addresses.
>
> Of course PIC code can't use these instructions to load absolute
> symbol addresses. This patch adds linker checks for linking objects
> using the relevant relocations into shared libraries, to detect the
> common mistake (for people coming from x86) of building objects
> without -fPIC and linking them into a shared library; the previous
> behavior was silently dropping the relocations and so generating a
> broken shared library, which is obviously undesirable.
>
> Tested with no regressions with cross to arm-none-eabi. OK to commit?
>
> This certainly does not fix every case of ARM relocations that are
> either always unsafe for objects linked into shared libraries, or
> unsafe for such objects if the symbol referenced might not be resolved
> within the library at runtime; there are many other cases that may
> have similar issues, but these are the ones observed to cause problems
> in practice. ("Unsafe" means not fully resolved at static link time
> and not converted to a dynamic relocation or no suitable dynamic
> relocation available to which to convert the relocation.)
This is OK, if it has survived a build of glibc.
--
Daniel Jacobowitz
CodeSourcery