further issues with x86 relocs

[Jan Beulich]

On 16.06.2021 15:47, Michael Matz wrote:
> On Tue, 15 Jun 2021, Jan Beulich wrote:
>> the first aspect here was, iirc, already mentioned in passing on a
>> relatively recent thread: Both ABIs specify e.g. GOT-or PLT-related
>> relocations to effectively be G(S)+A instead of G(S+A). (i386'es
>> GOT32 additionally bogusly says G+A-GOT, when G already is an offset
>> into GOT.) IMO the ABIs should be changed, but I'm not sure how
>> practical this is. In any event the present way of how things are
>> specified makes no sense with A != 0.
> 
> I'll certainly agree that things are strange and variously broken with 
> A != 0 (or A != -4 !),

Yeah, the -4 aspect occurred to me only after having hit the send button
already. With that, special_function(S+A) basically becomes not an
option at least in the rela case.

> but I'm not so sure about them making no sense.  Or 
> rather, that we could give them sense that somewhat flows naturally from 
> things.

What possible sense would you see?

>  I think currently, in most binary tools, the addend is either 
> ignored for these relocs, or added at the end, i.e. such that the final 
> value for any such relocation will be "special_function(symbol) + addend".
> 
> Now, the question is, should we specify that the addend be ignored?  (We 
> then at least need to think about what to do with the -4 addend on all 
> PC-relative relocs, because it can't be ignored; so "ignore-addend" as 
> solution isn't 100% clear-cut either)
> 
> Or should we specify different rules for dealing with addend than adding 
> at the end?  FWIW: I think not, the always-add-at-end rule seems simple 
> enough and is what mostly is implemented anyway, if it's not 
> ignore-addend.
> 
> I also think the real problems only start when thinking about how 
> relocations are transformed during the various object-code processing 
> phases.  E.g. from a simple and non-controversial PC32, via a PLT32 to 
> JUMP_SLOT/GLOB_DAT.  The meaning for addends seems clear enough for PC32 
> and GLOB_DAT, it just needs to be transferred correctly (and hopefully 
> obviously) by the intermediate steps.
> 
>> As it stands the assembler treats even something that is making
>> explicit how the addend is meant, like
>>
>> 	mov $(sym+1)@got, %eax
>>
>> the same as
>>
>> 	mov $sym@got+1, %eax
> 
> I would think the assembler should at least warn about the first use 
> (possibly indefinitely, or until we can give meaning to the corner cases 
> such that the first variant would work as the parantheses suggest).

And the unpredictable result of the 2nd is not something you'd consider
worth warning about?

>> and oddly enough also the same as
>>
>> 	mov $1@got+sym, %eax
> 
> Yeah, that probably should be rejected even, not just warned about.
> 
> Generally I'm not sure if we should (and even can) change the psABI, or if 
> there's even a need to start with.  As I mentioned the psABI currently 
> says add-at-end for most relocs, but it doesn't specify how relocations 
> are transformed (it doesn't have to because what needs to happen is 
> obvious: all relocation processing must be such that in the end the same 
> location is specified), so I don't really see where the psABI inherently 
> creates a problem.

Well, when the add-at-end clearly leads to unpredictable results, I'd
think it would be better that the psABI says addends are ignored (or
required to be a specific value, i.e. -4 in various cases). There's no
rule, after all, determining the order of e.g. GOT or PLT entries, so
one can't use an offset from one entry to deterministically reach
another one.

Jan