[PATCH V2] Support {evex} pseudo prefix for decode evex promoted insns without egpr32.
Cui, Lili
lili.cui@intel.com
Mon Apr 8 06:15:15 GMT 2024
> > For pop2 %rax,%r8, it only has EVEX format, it's special because its ins-
> >vex.nd != 0,so the normal process will not add {evex} to it, but we give it an
> illegal value, let ins->vex.nd = 0, so it added {evex} by mistake. This mistake is
> caused by illegal values. I don’t have a reasonable fix, so I prefer not to
> change it.
> > ------------------------------------------------------------------------------------
> > # pop2 %rax, %r8 set EVEX.ND=0.
> > .byte 0x62, 0xf4, 0x3c, 0x08, 0x8f, 0xc0
> > .byte 0xff, 0xff, 0xff
> > ----------------------------------------------------------------------
> > ---------------
>
> The POP2 aspect isn't really relevant here. Imo (bad) should never be
> prefixed by (pseudo) prefixes. If, however, it is to be, then such prefixing
> needs doing consistently. Which I'm afraid is going to be quite a bit more
> work than simply zapping (or avoiding) {evex} when (bad) is printed.
>
I added an early return in "putop()" when the instruction name is "(bad)". Since we don't want to add any prefix or suffix to "(bad)". Do you think it is okay?
@@ -10391,6 +10395,15 @@ putop (instr_info *ins, const char *in_template, int sizeflag)
int cond = 1;
unsigned int l = 0, len = 0;
char last[4];
bool evex_printed = false;
+ if (!strncmp (in_template, "(bad)", 5))
+ {
+ oappend (ins, "(bad)");
+ *ins->obufp = 0;
+ ins->mnemonicendp = ins->obufp;
+ return 0;
+ }
> >>> @@ -10398,6 +10402,7 @@ putop (instr_info *ins, const char
> >>> *in_template,
> >> int sizeflag)
> >>> int cond = 1;
> >>> unsigned int l = 0, len = 0;
> >>> char last[4];
> >>> + bool b_done = false;
> >>
> >> Mind me asking what "b" in this identifier is intended to stand for?
> >>
> >
> > I just want to show that it is a bool type. Maybe it would be better to
> change it to b_added_evex_prefix? Do you have any suggestions?
>
> I don't think we use such b_ prefixes elsewhere. "evex_printed" or some such
> would seem sufficient.
>
Done.
> >>> @@ -10588,7 +10604,11 @@ putop (instr_info *ins, const char
> >> *in_template, int sizeflag)
> >>> oappend (ins, "{nf} ");
> >>> /* This bit needs to be cleared after it is consumed. */
> >>> ins->vex.nf = false;
> >>> + b_done = true;
> >>> }
> >>> + else if (ins->evex_type == evex_from_vex && !(ins->rex2 & 7)
> >>> + && ins->vex.v)
> >>> + oappend (ins, "{evex} ");
> >>
> >> Why would b_done not need setting here as well?
> >>
> >
> > We only use b_done under "ins->evex_type == evex_from_legacy".
> Original version, we also handle "evex_from_legacy" here, now it is merged
> directly into "default:".
>
> Then leaving a trap for later? Let's keep internal state properly updated:
> If {evex} is printed, reflect that in local variable state, too.
>
Done.
Thanks,
Lili.
More information about the Binutils
mailing list