Re: [PATCH RESEND] x86: allow VEX et al encodings in 16-bit (protected) mode

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 25.06.19 at 16:52, <hjl.tools@gmail.com> wrote:
> On Tue, Jun 25, 2019 at 12:20 AM Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >>> On 24.06.19 at 18:30, <hjl.tools@gmail.com> wrote:
>> > On Mon, Jun 24, 2019 at 7:05 AM Jan Beulich <JBeulich@suse.com> wrote:
>> >> --- a/gas/config/tc-i386.c
>> >> +++ b/gas/config/tc-i386.c
>> >> @@ -4387,9 +4387,9 @@ md_assemble (char *line)
>> >>
>> >>    if (is_any_vex_encoding (&i.tm))
>> >>      {
>> >> -      if (flag_code == CODE_16BIT)
>> >> +      if (!cpu_arch_flags.bitfield.cpui286)
>> >>         {
>> >> -         as_bad (_("instruction `%s' isn't supported in 16-bit mode."),
>> >> +         as_bad (_("instruction `%s' isn't supported outside of protected 
> mode."),
>> >>                   i.tm.name);
>> >>           return;
>> >>         }
>> >
>> > flag_code == CODE_16BIT is used to indicate 16-bit mode, in most cases, for 
> real
>> > mode.   If there are real use cases for VEX/EVEX insns in 16-bit protected 
> mode,
>> > should we add a directive or pseudo prefix to indicate protected mode 
> encoding?
>>
>> Not sure - I'd leave that to you. All I want/need is to be able encode
>> VEX/XOP/EVEX insns for 16-bit protected mode use. How about we go
>> with this patch for now, and you further refine things to your liking
>> subsequently?
>>
> 
> Up to now, flag_code == CODE_16BIT disallows VEX/EVEX encoding.

And wrongly so, imo. Hence this patch.

>  I
> think VEX/EVEX encoding should be allowed only under a new directive.

To be honest, I'm not really up to doing this work, not the least because
I assume there might be other things that then ought to be made
protected mode only (and I also wouldn't want to contribute a half baked
implementation). Hence once again my suggestion: Let's go with this
patch for now, and if you think things need to be restricted again a little
more, you can follow up with a change implementing the new directive
(and all its ramifications beyond VEX/EVEX handling, if any).

Jan