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

[Jan Beulich]

On 07.02.2024 18:03, H.J. Lu wrote:
> On Wed, Feb 7, 2024 at 8:59 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 07.02.2024 17:53, H.J. Lu wrote:
>>> On Wed, Feb 7, 2024 at 7:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 07.02.2024 16:24, H.J. Lu wrote:
>>>>> On Tue, Feb 6, 2024 at 11:51 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 06.02.2024 19:06, H.J. Lu wrote:
>>>>>>> On Tue, Feb 6, 2024 at 9:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 06.02.2024 17:28, H.J. Lu wrote:
>>>>>>>>> With as_bad, assembler will continue to assemble, just not generate
>>>>>>>>> an object file.   We ran into this with APX.  Not everyone checks
>>>>>>>>> assembler warnings closely.  It led to mysterious crashes.   I am
>>>>>>>>> not against it if someone else implements an assembler option to
>>>>>>>>> turn this error into a warning.
>>>>>>>>
>>>>>>>> But it should be the other way around: The compiler could pass an
>>>>>>>> option to promote the (default) warning to an error. And if you
>>>>>>>> don#t pay attention to warning for assembly files, you could pass
>>>>>>>> the same option as well. Without harming anyone else with anything
>>>>>>>
>>>>>>> People who use/need instructions > 15 bytes belong to a very small
>>>>>>> minority.  If they want to do it, they can use .insn or use binutlls 2.41
>>>>>>> or older.  The default assembler isn't for them.
>>>>>>
>>>>>> No, staying on an old assembler isn't viable. And minority or not, you
>>>>>> have to face it: In the present discussion it is you who represents a
>>>>>> minority. As such I'm even inclined to suggest that your earlier patch
>>>>>> wants reverting, on the basis that it was put in despite there being
>>>>>> disagreement. Unless you soon come forward with an incremental change
>>>>>> undoing at least the worst of its effects ...
>>>>>
>>>>> Please tell me exactly which projects are negatively impacted by
>>>>> disallowing > 15 byte instructions.
>>>>
>>>> I already told you: I'm using such in testing of my personal disassembler
>>>> library.
>>>
>>> So, it is only you.  You can either use .insn or add a switch to turn
>>> this error to warning.
>>
>> I has been a warning until 2.42, which you've regressed for my use case.
>> This is why I expect you to at least soften the regression, in allowing
>> people like me to simply add a command line option to the gas invocations.
> 
> So this is for your personal use case.  If you asked nicely, I might have
> considered spending my time on this.

Well, to be blunt: I would have asked more nicely if you hadn't overridden
my concern. The more that this isn't the first time that you went ahead
with changes without having reached consensus.

>> Plus, as you have learnt from Michael's responses, I'm not the only one
>> to think that this diagnostic ought to continue to be a warning by
>> default.
> 
> I can also tell you that there are other binutils developers who want to
> treat this as an error.   Should I ask them for their opinions?

>From further reactions I can see that I suddenly moved to the minority. So
be it then, so long as a future patch to allow this diagnostic to be
converted to a warning won't be blocked.

Jan