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

["H.J. Lu" <hjl.tools@gmail.com>]

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?

-- 
H.J.