[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