[PATCH 1/6] RISC-V bfd port
Andrew Waterman
andrew@sifive.com
Wed Oct 12 18:48:00 GMT 2016
On Tue, Oct 11, 2016 at 6:57 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Oct 11, 2016 at 06:17:59PM -0700, Andrew Waterman wrote:
>> On Tuesday, October 11, 2016, Alan Modra <amodra@gmail.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."
>
> --
> Alan Modra
> Australia Development Lab, IBM
More information about the Binutils
mailing list