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

[Jan Beulich <jbeulich@suse.com>]

On 08.02.2024 07:41, Cui, Lili wrote:
>>> When a warning is given, a decodable instruction should still be
>>> generated.
>>
>> A software library can decode such instruction just fine.  A human as well.
>>
>>> Assembler shouldn't generate something which can't be decoded by
>>> default.
>>
>> That's the important words: "by default".  Here's the documentation for
>> as_bad and as_warn:
>>
>>    as_bad() is used to mark errors that result in what we
>>    presume to be a useless object file.  Say, we ignored
>>    something that might have been vital.
>>    ...
>>
>>    as_warn() is used when we have an error from which we
>>    have a plausible error recovery.  eg, masking the top
>>    bits of a constant that is longer than will fit in the
>>    destination.  In this case we will continue to assemble
>>    the source, although we may have made a bad assumption,
>>    and we will produce an object file and return normal exit
>>    status (ie, no error).
>>    ...
>>
>> It's obvious to me that just continuing to assemble the over-long instruction is
>> a "plausible error recovery".  It's even more plausible than "masking the top
>> bits of a constant".  Certainly an object file containing a byte sequence
>> correspending to the overlong instruction is not "useless".
>>
>> I understand why you want to give an error by default, even though I disagree
>> with even that (in my book only a warning is justified).  But ruling out that this
>> can be demoted to a warning, possibly with an option, is not in line with my
>> expectation of how the GNU assembler should work and has traditionally
>> worked.
>>
> 
> It is a hardware limitation. Once an incorrect command occurs, it will be difficult to locate. This is a critical issue and should be reported as an error, especially with the addition of APX our prefixes are becoming more complex and diverse, it's time to make a change.

I find this (including H.J.'s) position odd: Until me introducing the
warning, no-one cared at all. Presumably because, as indicated before,
Intel ISA extensions weren't really affected. Now suddenly everyone's
calling for an even stronger diagnostic. IOW if there is a concern now,
the same concern should have been there many years earlier.

Jan