[PATCH] x86: Update register operand check for AddrPrefixOpReg

H.J. Lu hjl.tools@gmail.com
Wed Oct 7 18:17:46 GMT 2020


On Fri, Oct 2, 2020 at 5:27 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Oct 2, 2020 at 5:18 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 02.10.2020 13:33, H.J. Lu wrote:
> > > On Thu, Oct 1, 2020 at 11:58 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >> On 01.10.2020 17:08, H.J. Lu wrote:
> > >>> GNU assembler accommodates other usages.  But it must work with GCC.
> > >>
> > >> We agree on this. What you don't want to accept is that gcc also
> > >> needs to emit correct code for gas to consume.
> > >>
> > >>> In this case, it needs to check the register operand for the address size prefix
> > >>> when the memory operand is (%rip).
> > >>
> > >> And we again agree on the checking aspect. What we disagree on is
> > >> what to do if the check finds a discrepancy. Without your recent
> > >> change, the checking you talk about did already happen. And the
> > >> assembler correctly diagnosed it. The assembler may not _ever_
> > >> guess upon what the programmer meant, when finding an ambiguity
> > >> (exceptions to this rule may be warranted for backwards
> > >> compatibility in very rare cases, but this clearly doesn't apply
> > >> here). We've had this discussion before in different contexts,
> > >> and I have to admit I'm struggling with how you drive things in
> > >> this regard. If there was a way for gcc to indicate "I've done my
> > >> best, but please fix it up for me", I could accept there being
> > >> such a (non-default) mode. I wouldn't like it very much, but I
> > >> could live with it. But for hand-written code (be it entire .s
> > >> files or inline assembly) inconsistencies and ambiguities need to
> > >> be diagnosed by default.
> > >>
> > >> Note in particular that your change isn't even limited to x32
> > >> mode, where one _might_ view the adjustment as benign.
> > >
> > > The address size prefix isn't limited to x32.   For RIP-relative
> > > addressing, GCC always uses (%rip).
> >
> > But the issue at hand is limited to x32, and the conversion you're
> > doing is also only half-way safe for x32.
>
> This is about the address size prefix in encoding and x32 uses it.
>
> > >  The assembler will never
> > > guess correctly what the assembly code is trying to do in all
> > > cases.
> >
> > Hence it shouldn't guess. It should tell the programmer to change
> > the code so guessing isn't needed.
>
> GCC uses (%rip) for RIP relative addressing since there is no
> need for the address size prefix for x32 and x86-64.  It is the same
> as DISP and SYMBOL memory operand.   This is how GCC works.
> Assembler just needs to check the register operand for the address
> size prefix.
>
> > >  In this particular case, the assembler needs to look
> > > at the register operand to extract the address size prefix.
> >
> > And how does it know _that's_ the part which is correct (as per
> > the programmer's intentions), and not the other operand?
> >
>
> In this case, just extract the address size prefix from the register
> operand.
>

I am backporting these 2 patches to 2.34 and 2.35 branches.

-- 
H.J.


More information about the Binutils mailing list