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

[H.J. Lu]

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.

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

-- 
H.J.