[PATCH 3/6] x86: harmonize disp with imm handling

[Jan Beulich]

On 22.06.2021 16:01, H.J. Lu wrote:
> On Tue, Jun 22, 2021 at 6:22 AM Michael Matz <matz@suse.de> wrote:
>>
>> Hello,
>>
>> On Fri, 18 Jun 2021, H.J. Lu via Binutils wrote:
>>
>>>> You realize that for the purpose of the test case the -0xffffffff is
>>>> an over-simplification of what might appear in "real" code, don't
>>>> you? It also feels as if you didn't really read my earlier remark:
>>>
>>> I don't think treating -0xffffffff as 1 here helps anyone.
>>
>> The assembler should not be too much in the business of constraining users
>> with well-intended but badly implemented rules.  The -0xffffffff isn't
>> actually a literal, it's an (assembler) operation applied to a literal.
>> The wraparound that does or doesn't happen is _internal_ to the assembler,
>> the hardware doesn't enter the picture.  -0xffffffff only means '1'
>> because the assembler internally represents this as 32bit entity, again
>> without the hardware mattering.  (And if it were using a different-sized
>> internal field it would or wouldn't warn on different input ranges, and if
>> that size then depends on how BFD is configured that would be very bad).
>>
>> Further it's quite probable that the '-' actually comes from e.g. a macro
>> expansion, it's for instance feasible to write a macro that offsets
>> something by a constant in both directions:
>>
>> #define sub2(reg, B, D) \
>>   movq D(B), reg \
>>   addq -D(B), reg
>>
>> Now it's completely opaque why the user should be warned about this:
>>
>>   sub2(%rax, %rdi, 0xffffffff)
>>
>> but not about this:
>>
>>   sub2(%rax, %rdi, 1)
>>
>> What you are saying is equivalent to say to also warn about uses of '--1',
>> after all the user "should have simply used "1"'.  Extended such makes it
>> obvious that the warning is unwarranted, because then there wouldn't even
>> be a work-around for the above situation anymore, you can't write
>> sub2(%rax,%rdi,0xffffffff) and you can't write sub2(%rax,%rdi,-1).
>>
>> I would perhaps agree that if a user literally would write '-0xffffffff'
>> except in a testcase that a warning might be appropriate, in something
>> that's designed to teach good style to assembler programmers perhaps.  But
>> not in GNU as.  It would be a warning that can't be silenced and happens
>> in perfectly valid code, so, no.
>>
>> All in all: I think the assembler should be entirely silent about any of
>> these literals modified by assembler operations.
> 
> A 32bit displacement is signed with R_X86_64_32S.  For
> 
> mov disp(%rax), %eax
> 
> should linker issue an error if disp == -0xffffffff?

I think so, yes. In fact I'd hope the assembler would already not allow
this, -0xffffffff actually being 0xffffffff00000001 in 64-bit arithmetic.
What we've been discussing here so far were issues with 32-bit addressing
(and wrapping of involved arithmetic).

Jan