This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/6] RISC-V bfd port
On Wed, Oct 12, 2016 at 4:41 PM, Alan Modra <email@example.com> wrote:
> On Wed, Oct 12, 2016 at 11:47:26AM -0700, Andrew Waterman wrote:
>> On Tue, Oct 11, 2016 at 6:57 PM, Alan Modra <firstname.lastname@example.org> wrote:
>> > On Tue, Oct 11, 2016 at 06:17:59PM -0700, Andrew Waterman wrote:
>> >> On Tuesday, October 11, 2016, Alan Modra <email@example.com> wrote:
>> >> > On Tue, Oct 11, 2016 at 04:46:06PM -0700, Andrew Waterman wrote:
>> >> > > +/* Remember all PC-relative high-part relocs we've encountered to help
>> >> > us
>> >> > > + later resolve the corresponding low-part relocs. */
>> >> >
>> >> > Why? This sort of thing is usually only needed on REL targets.
>> >> We'll expound on this comment to explain our strategy. Of course, a simpler
>> >> approach might suffice.
>> > It's not a matter of explaining. I think you have something seriously
>> > wrong here. You most likely need to remove all of the hi/lo recording
>> > and use of high value to apply low relocs, or you have a broken ABI.
>> > If the latter then it would pay to fix it sooner rather than later.
>> > The reason hi/lo matching is needed on REL targets is that with the
>> > addend stored in the insn you can only fit a partial addend in an
>> > insn. You need to read both insns and combine the addends to create a
>> > full addend (which is needed to properly perform pc subtraction).
>> > With RELA targets you should have the full addend in the reloc.
>> It's not that a partial addend is being stored anywhere; it's that
>> there is a level of indirection. The PC-relative addressing scheme is
>> relative to the address of the high-part reloc, because of how the ISA
>> works. So, the value of the low-part reloc depends both on the
>> address of the high-part reloc and the symbol being referenced. The
>> alternative would be to put two relocs on the low-part (one for the
>> symbol being referenced and one for the high-part reloc). The
>> indirect approach seems cleaner to me.
>> An example might clarify:
>> 0x1234: auipc t0, %pcrel_hi(sym)
>> 0x1338: addi t0, t0, %prcrel_lo(0x1234)
>> sym = 0x45678
>> The %pcrel_lo needs to be filled in with ((0x45678 - 0x1234) & 0xFFF).
>> This approach is perhaps unconventional, but it is hard to see why it
>> is "seriously wrong."
> I see. Yes, if you explicitly reference the hi reloc from the lo one
> that's not so bad. I thought you may have been trying to associate
> the two in the linker, which has lots of ways to go wrong.
I'm glad we concur!
> Note that power9 has something similar with addpcis/addi pairs where
> we write:
> addpcis 9,(sym - .L0)@ha
> addi 9,9,(sym - .L0)@l
> producing (... is two nops in this example)
> 0000000000000000 <.text>:
> 0: 04 00 20 4d addpcis r9,0
> 0: R_PPC64_REL16DX_HA sym
> 4: 00 00 00 60 nop
> 8: 00 00 00 60 nop
> c: 00 00 29 39 addi r9,r9,0
> c: R_PPC64_REL16_LO sym+0xc
> This way both addpcis and addi insns have exactly the same reloc
> symbol and each can be relocated independently. The addpcis insn
> reloc has an addend of -.L0, zero in this case, while the addi insn
> reloc addend is the difference between the two insn addresses.
> Things get a little tricky with linker relaxation involving deletion
> or insertion of insns (which powerpc64 ld doesn't support), but I
> imagine you might have similar problems if linker relaxation moves
> your auipc insn.
I didn't realize another port had to address a similar issue. Thanks
for the pointer.
The indirect approach is tolerant to intervening linker relaxations,
because the delta between hi and lo doesn't factor into the final
computation; in the end, it's just the LSBs of (sym - hi). The power9
approach seems cleaner if the delta can be computed at assembly time,
but relaxation does preclude that.
> Alan Modra
> Australia Development Lab, IBM