Re: Fix assembly of Thumb pcrel LDRs against global symbols

[Richard Sandiford <richard.sandiford@linaro.org>]

Richard Earnshaw <rearnsha@arm.com> writes:
> On Mon, 2011-02-28 at 12:59 +0000, Richard Sandiford wrote:
>> The PC-relative LDR instructions have no associated relocation,
>> so even LDRs for global symbols should be resolved by the assembler.
>> We currently handle this correctly for single-register ARM loads,
>> but we're missing the associated relocation types for LDRD and Thumb.
>> This leads to errors like:
>
> I'm not sure I agree with this.  If I write
>
> .global foo
>
> ...
> 	ldr r0, foo
>
> ...
>
> foo:
> 	...
>
> but then at link/load time pre-empt foo with some other definition, that
> will silently leave me with the wrong answer.

Yeah, I realise we normally try to do that.  The point was that we
already resolve these references at assembly time for ARM LDRs --

	.syntax	unified

	ldr	r3,foo
	nop
	.globl	foo
foo:
	.word	0x1234

-- just not for Thumb LDRs or for (any) LDRDs.  I think I'd wrongly assumed
that the current ARM LDR behaviour was by design, and that we should make
the other cases match.  However, looking at the ABI again, I see there is
a reloc (R_ARM_THM_PC12) that we can use here, but that we aren't using.

So if the current ARM behaviour is wrong, then I suppose there are
three bugs:

- We're using a generic ARM_OFFSET_IMM fixup for ARM LDRs, which is
  always getting resolved by the assembler.  We should generate a
  reloc instead for this case (but not for some other ARM_OFFSET_IMM cases).

- We're using a generic T32_OFFSET_IMM fixup for Thumb LDRs, which is
  always triggering an error (one of the two in my message).  We should
  generate a reloc instead (but not for some other T32_OFFSET_IMM cases).

- We generate the internal error for things like:

	.syntax	unified
	.thumb_func

	ldr	r3,[r12,#foo-.]
	nop
	.globl	foo
foo:
	.word	0x1234

  which AFAICS couldn't be handled by relocations.  (The patch fixes
  this too.)

That's a bit more work than I'd anticipated, and the first change might
annoy some people, so I think I'd better put it to one side for now. :-)

Richard