[PATCH 1/8] ARM: assembler: introduce adr_l, ldr_l and str_l macros

[Ard Biesheuvel]

On 4 August 2016 at 13:08, Dave Martin <Dave.Martin at arm.com> wrote:
> On Thu, Aug 04, 2016 at 12:12:07PM +0200, Ard Biesheuvel wrote:
>> On 4 August 2016 at 11:38, Dave Martin <Dave.Martin at arm.com> wrote:
>> > On Thu, Aug 04, 2016 at 09:40:50AM +0200, Ard Biesheuvel wrote:
>> >> On 3 August 2016 at 20:09, Russell King - ARM Linux
>> >> <linux at armlinux.org.uk> wrote:
>> >> > On Wed, Aug 03, 2016 at 05:38:43PM +0200, Ard Biesheuvel wrote:
>> >> >> +     add     \dst, pc, #:pc_g0_nc:(\sym) - 8
>> >> >> +     add     \dst, \dst, #:pc_g1_nc:(\sym) - 4
>> >> >> +     add     \dst, \dst, #:pc_g2:(\sym)
>> >> >
>> >> > What's this :pc_g0_nc: stuff?  What binutils versions is it supported
>> >> > in?  It doesn't appear documented in gas 2.23.91, so I don't think we
>> >> > can use it.
>> >> >
>> >>
>> >> binutils 2.18 and up
>> >
>> > I think this was contemporary with GCC 4.<some middling version>, which
>> > may be newer than the minimimum compiler we require for the kernel,
>> > particular for earlier arch versions.
>> >
>> > Using .reloc probably allows the same thing to be done in a more
>> > backwards-compatible way.
>> >
>>
>> I don't see how LD would know how to handle these relocations if we do
>> manage to emit them from GAS in this way.
>
> 0:      add     \dst, pc, #-8
> 1:      add     \dst, \dst, #-4
> 2:      add     \dst, \dst, #0
>
> .reloc  0b, R_ARM_ALU_PC_G0_NC, \sym
> .reloc  1b, R_ARM_ALU_PC_G1_NC, \sym
> .reloc  2b, R_ARM_ALU_PC_G2, \sym
>
> or, for ldr_l:
>
> 0:      add     \dst, pc, #-8
> 1:      add     \dst, \dst, #-4
> 2:      ldr     [\dst, #0]
>
> .reloc  0b, R_ARM_ALU_PC_G0_NC, \sym
> .reloc  1b, R_ARM_ALU_PC_G1_NC, \sym
> .reloc  2b, R_ARM_LDR_PC_G2, \sym
>
> ... should produce precisely the same result at the .o stage.
>

Yes, but how is LD going to perform the arithmetic involved in
handling these relocations? That's is the more interesting part, and
that is not implemented either in binutils < 2.18

>
> This #:reloc: stuff is mostly a shorthand/convenience feature as I
> understand it -- however, you do have to know how to force the correct
> instruction encoding to be emitted to match the reloc type -- with
> #:reloc:, the assembler should take care of that.
>
> The reloc/insn match issue also means that the Thumb2 relocs are
> totally different (R_ARM_THM_<blah>).
>
>
> For OABI, it would no doubt be different again.  I know nothing about
> OABI relocs.
>
> And we're still limited to <32-bit offset ranges.
>

Indeed. As I said, a dead end ...