RE: [PATCH 1/8] Support APX GPR32 with rex2 prefix

["Cui, Lili" <lili.cui@intel.com>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, November 10, 2023 5:22 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; ccoutant@gmail.com;
> binutils@sourceware.org
> Subject: Re: [PATCH 1/8] Support APX GPR32 with rex2 prefix
> 
> On 10.11.2023 10:14, Jan Beulich wrote:
> > On 10.11.2023 08:11, Cui, Lili wrote:
> >> Here are some cases:
> >> 0:   41 0f a8                  rex.B push %gs         ---> rex.B was not consumed, rex
> will print it.
> >> 0:   d5 01 0f a8             {rex2} push %gs      ----> Without egpr, we need to
> print {rex2} for it. But we can't see anything about REX2.B3 from the prefix.
> >> 4:   d5 19 58                  pop    %r24             ----> There is egpr, we know it
> uses rex2 prefix. We cannot see the information of the lower 4 bits of rex2
> >>
> >> It is not helpful to judge rex_used in rex2.
> >
> > So: REX2, like REX, is a prefix for legacy encodings. Therefore my
> > view is that it ought to be treated similarly to REX in the
> > disassembler (I'm fine to avoid the introduction of a myriad of
> > rex2... [no figure braces] prefixes in gas). Just like in the first
> > line of what you present above for the REX.B case, I'd expect the same
> > for REX2. E.g., taking the 2nd line from above
> >
> > 0:   d5 01 0f a8             {rex2.B3} push %gs
> >
> > An alternative, matching your intention of treating REX2 more like
> > EVEX, would be to (subsequently, not right away) do away with rex.B
> > and alike as well, and only print {rex} in that case as well. Such an
> > intention would then want mentioning in the description (and
> > eventually carrying out). The main difference between REX/REX2 and
> > VEX/EVEX, as I view it (and as would be speaking against this
> > alternative approach), is that in VEX/EVEX it is kind of normal that
> > certain bits are deliberately ignored (and might be set either way -
> > see gas'es command line options actually allowing to drive the values for
> some of such ignored fields).
> > REX/REX2, otoh, shouldn't normally specify unused bits, much like
> > other legacy prefixes aren't expected to be present for no reason (and
> > hence are explicitly printed when present).
> 
> However, irrespective of what I said above, please feel free to go ahead with
> the simplified approach, to allow making progress. I'd like to have H.J.'s input
> on how to achieve overall consistency, and we can make further adjustments
> later on. But please make sure you actually mention this aspect in the
> description of the patch.
> 

OK, I'll add a description of the current implementation.

Thanks,
Lili.