On Mon, Jan 4, 2016 at 10:59 AM, Tony Luck <tony.luck@xxxxxxxxx> wrote:
>> ----- begin comment -----
>>
>> The offset to the fixup is signed, and we're trying to use the high
>> bits for a different purpose. In C, we could just do:
>>
>> u32 class_and_offset = ((target - here) & 0x3fffffff) | class;
>>
>> Then, to decode it, we'd mask off the class and sign-extend to recover
>> the offset.
>>
>> In asm, we can't do that, because this all gets laundered through the
>> linker, and there's no relocation type that supports this chicanery.
>> Instead we cheat a bit. We first add a large number to the offset
>> (0x20000000). The result is still nominally signed, but now it's
>> always positive, and the two high bits are always clear. We can then
>> set high bits by ordinary addition or subtraction instead of using
>> bitwise operations. As far as the linker is concerned, all we're
>> doing is adding a large constant to the difference between here (".")
>> and the target, and that's a valid relocation type.
>>
>> In the C code, we just mask off the class bits and subtract 0x20000000
>> to get the offset.
>>
>> ----- end comment -----
>
> But presumably those constants get folded together, so the linker
> is dealing with only one offset. It doesn't (I assume) know that our
> source code added 0x20000000 and then added/subtracted some
> more.
Yes, indeed.
>
> It looks like we could just use:
> class0: +0x40000000
> class1: +0x80000000 (or subtract ... whatever doesn't make the linker cranky)
> class2: -0x40000000
> class3: don't add/subtract anything
>
> ex_class() stays the same (just looks at bit31/bit30)
> ex_fixup_addr() has to use ex_class() to decide what to add/subtract
> (if anything).
>
> Would that work? Would it be more or less confusing?
That probably works, but to me, at least, it's a bit more confusing.
It also means that you need a table or some branches to compute the
offset, whereas the "mask top two bits and add a constant" approach is
straightforward, short, and fast.
Also, I'm not 100% convinced that the 0x80000000 case can ever work
reliably. I don't know exactly what the condition that triggers the
warning is, but the logical one would be to warn if the actual offset
plus or minus the addend, as appropriate, overflows in a signed sense.
Whether it overflows depends on the sign of the offset, and *that*
depends on the actual layout of all the sections.
Mine avoids this issue by being shifted by 0x20000000, so nothing ends
up right on the edge.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>