Re: ARM pc-relative loads

[Richard Earnshaw <rearnsha at arm dot com>]

On Tue, 2011-05-31 at 15:10 +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.
> 
> Tested on arm-none-eabi
> Applied to CVS head
> 
> Paul
> 
> 2011-05-31  Paul Brook  <paul@codesourcery.com>
> 
> 	gas/
> 	* config/tc-arm.c (arm_force_relocation): Resolve all pc-relative
> 	loads.
> 
> 	gas/testsuite/
> 	* gas/arm/ldr-global.d: New test.
> 	* gas/arm/ldr-global.s: New test.

Hmm, your patch contains additional things not relevant to this
discussion.

I've been thinking about this problem.  My feeling is that, strictly, if
a user wants an internal relocation then they should just mark the
symbol as being visibility protected, or private, or make the symbol
really local if that's what it should be.  I'm not convinced that
propagating a bug in the ARM code support to the Thumb support is the
right way forward.

R.