[PATCH] x86: Warn .insn instruction with length > 15 bytes

[H.J. Lu]

On Tue, Feb 6, 2024 at 3:41 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.02.2024 12:36, H.J. Lu wrote:
> > On Tue, Feb 6, 2024 at 12:19 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 05.02.2024 21:00, H.J. Lu wrote:
> >>> Change .insn instruction with length > 15 bytes from error to warning.
> >>
> >> Thanks for doing this. FTAOD though - it addresses only half of my
> >> concern. Besides .insn (where the concern was of general nature) I
> >> also use
> >>
> >>         bextr   eax, fs:[eax*4], 0x11223344
> >>         xacquire lock add qword ptr gs:[eax*8], 0x11223344
> >>
> >> in testing of my own disassembler library. I expect to continue to
> >> be able to avoid using .insn (and even more so .byte) when assembling
> >> this code. IOW there will still need to be a way to also override
> >> the defaulting to as_bad() when not using .insn.
> >
> > We issue a warning when something is wrong in input, but still manage
> > to generate an instruction.   This is an error case.
>
> I disagree. It was a warning until you changed it (without me really
> agreeing), and some hypothetical vendor could come and lift the limit,
> on precisely the basis that there are legal encodings exceeding it. I'm
> okay if this can be forced to be an error, but I continue to think that
> it ought to be a warning only by default.
>

It is an error on both Intel and AMD processors.   There is no
valid reason not to be an error at the moment.  We can change
it when there is such a vendor in the future.

-- 
H.J.