[PATCH] Support APX NF

[Jan Beulich]

On 01.03.2024 12:36, Cui, Lili wrote:
>>> @@ -9147,6 +9150,10 @@ get_valid_dis386 (const struct dis386 *dp,
>> instr_info *ins)
>>>        ins->vex.v = *ins->codep & 0x8;
>>>        ins->vex.mask_register_specifier = *ins->codep & 0x7;
>>>        ins->vex.zeroing = *ins->codep & 0x80;
>>> +      /* Set the NF bit for the EVEX instruction extended from the legacy or
>>> +	 vex instruction, this bit will be cleared when it can be confirmed
>>> +	 that its defaut type is evex.  */
>>> +      ins->vex.nf = *ins->codep & 0x4;
>>>
>>>        if (ins->address_mode != mode_64bit)
>>>  	{
>>> @@ -9600,6 +9607,15 @@ print_insn (bfd_vma pc, disassemble_info *info,
>> int intel_syntax)
>>>  	  && ins.vex.prefix == DATA_PREFIX_OPCODE)
>>>  	sizeflag ^= DFLAG;
>>>
>>> +      if(ins.evex_type == evex_default)
>>> +	ins.vex.nf = false;
>>
>> Up to here I think I agree.
>>
>>> +      else
>>> +	/* For EVEX-promoted formats, we need to clear EVEX.NF (For ccmp
>> and
>>> +	   ctest, they will be cleared separately.) in mask_register_specifier
>>> +	   and keep the low 2 bits of mask_register_specifier to report errors
>>> +	   for invalid cases.*/
>>> +	ins.vex.mask_register_specifier &= 0x3;
>>
>> But this I'm in trouble with: How would you recognize (and accordingly print)
>> insns with NF wrongly set? (By implication there's also a respective testcase
>> [addition] missing.)
>>
> 
> For the else branch here, "ins.vex.mask_register_specifier" and "ins.vex.nf" store the same value, I just clean the redundant one. Otherwise, NF bit in "ins.vex.mask_register_specifier" will be printed out as a k register later. But we still need the 2 low bits to know the original value, we will use them in subsequent patches.
> 
> Jan, is it necessary to report bad for NF?

I think so, unless I've overlooked the doc somewhere saying that the flag
wrongly set is ignored (rather than causing #UD).

> We need to set a new flag in putop() for instructions that have %NF, then after putop() we can know if NF bit is set incorrectly, which is a bit ugly. Do you have a better way?

I think what you describe basically matches what we do elsewhere. Whether
a separate flag is needed I can't tell right away, but it seems likely.

Jan