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

["H.J. Lu" <hjl.tools@gmail.com>]

On Sun, Feb 4, 2024 at 11:41 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.

15 bytes is a hard limit, which also applies to APX.  When the size
limit is increased for a new ISA in the future, we will allow the bigger
size only for the specific ISA.

> - .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.
>

I will see what I can do about it.

-- 
H.J.