ARM pc-relative loads
Dave Martin
dave.martin@linaro.org
Thu Jun 2 10:06:00 GMT 2011
On Tue, May 31, 2011 at 03:10:22PM +0100, Paul Brook wrote:
> The patch below fixes a failure observed building a hacked-up variant of the
> linux kernel.
>
> The assembler is failing to resolve a pc-relative Thumb load from a global
> symbol in the same section. My first guess was that this is a feature -
> symbol preemption requires the address be resolved at dynamic link time.
> However the offset range of pc-relative load instructions is sufficiently
> small that I don't believe that symbol preemption would ever actually succeed
> in practice.
>
> We already resolve the equivalent ARM relocation. Arguably this is a bug.
> However there is code that relies on this behavior. Given the uselessness of
> exporting these relocations I've chosen to go for consistency with ARM LDR,
> and resolve the relocation. Further investigation revealed a handful of other
> load instructions that also need to be handled.
Whatever way this issue is finally resolved, we should resolve the behaviour
of pc-relative add and sub (i.e., adr and related instructions) in the
same way.
The behaviour of adr is currently strange in Thumb-2 on trunk:
adr to a word-aligned global symbol fails (even with .hidden etc.):
tst.s:11: Error: invalid immediate for address calculation (value = 0x00000004)
However, adr to a halfword-aligned global symbol succeeds, causing a
32-bit addw encoding to be generated. Similarly, adr referencing a
global symbol on any alignment before the reference generates 32-bit
subw encodings with no error.
adr to local symbols succeeds in all cases.
Should I report a bug on this, or does it make sense to look at it as part
of your corrent changes?
Cheers
---Dave
More information about the Binutils
mailing list