Re: [PATCH v2] x86: Disallow instructions with length > 15 bytes

[Jan Beulich <jbeulich@suse.com>]

On 02.02.2024 12:49, H.J. Lu wrote:
> On Fri, Feb 2, 2024 at 3:41 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 02.02.2024 12:33, H.J. Lu wrote:
>>> --- a/gas/config/tc-i386.c
>>> +++ b/gas/config/tc-i386.c
>>> @@ -11780,8 +11780,8 @@ output_insn (const struct last_insn *last_insn)
>>>       {
>>>         j = encoding_length (insn_start_frag, insn_start_off, frag_more (0));
>>>         if (j > 15)
>>> -         as_warn (_("instruction length of %u bytes exceeds the limit of 15"),
>>> -                  j);
>>> +         as_bad (_("instruction length of %u bytes exceeds the limit of 15"),
>>> +                 j);
>>
>> When taking purely a gas perspective, this may be okay. But I'd like
>> to retain the ability to generate overlong insns (without resorting
>> to .byte), so there wants to be a way to downgrade the error to a
>> warning. This is useful in particular when trying to make testcases
>> for disassemblers or other software decoding insns.
> 
> I am checking it in now and backport it to 2.42 branch.   We can add
> a switch or a directive later to downgrade error to warning.

Putting on the branch should be (have been?) deferred until the complete
solution is in place. 2.42.1 could be cut from it at basically any time,
at which point your change would regress the particular case I've been
mentioning. Furthermore I have to raise two more points:
- The 15-byte limit - while long-standing - being rather arbitrary, it
  could in principle be changed (bumped) at any time (as indicated, I
  think the latest with APX it should be bumped). Whenever such a bump
  occurs, the assembler outright refusing to assemble respective insns
  will be a problem.
- .insn is particularly intended to permit encoding things the assembler
  may not otherwise be able to encode. Therefore the diagnostic there
  ought to be more relaxed than for "ordinary" insns.

Jan