public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Hongyu Wang <wwwhhhyyy333@gmail.com>,
	"Jiang, Haochen" <haochen.jiang@intel.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>,
	Michael Matz <matz@suse.de>
Subject: Re: [PATCH] x86: Warn .insn instruction with length > 15 bytes
Date: Thu, 8 Feb 2024 09:15:20 +0100	[thread overview]
Message-ID: <fe4cc5e9-fa24-41ed-ba10-f4bddfc929b4@suse.com> (raw)
In-Reply-To: <CA+OydWk2aYb8Ec3th3BbFKt9A1LHO_KSvdFUrhB7VqnthOXwbg@mail.gmail.com>

On 08.02.2024 05:47, Hongyu Wang wrote:
>>    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".
> 
> We have encountered such issue when running APX workloads with SDE.
> The over-long instruction became either illegal or wrong instruction
> when executing the program, then it crashes after long time running.
> This definitely increases much effort for runtime diagnostics.

Well, that's what you get for not paying attention to diagnostics.
They aren't emitted just for fun.

Jan

> As the over-long instruction would actually break the program, say the
> object crashes or returns with abnormal exit status, the default
> should be an error for assembler and we can add an option to lower the
> error to warning.


  reply	other threads:[~2024-02-08  8:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 20:00 H.J. Lu
2024-02-06  8:19 ` Jan Beulich
2024-02-06 11:36   ` H.J. Lu
2024-02-06 11:41     ` Jan Beulich
2024-02-06 12:26       ` H.J. Lu
2024-02-06 14:43         ` Michael Matz
2024-02-06 14:49           ` H.J. Lu
2024-02-06 15:04             ` Michael Matz
2024-02-06 15:34               ` H.J. Lu
2024-02-06 15:48                 ` Michael Matz
2024-02-06 16:28                   ` H.J. Lu
2024-02-06 17:05                     ` Jan Beulich
2024-02-06 18:06                       ` H.J. Lu
2024-02-07  7:51                         ` Jan Beulich
2024-02-07 15:24                           ` H.J. Lu
2024-02-07 15:32                             ` Jan Beulich
2024-02-07 16:53                               ` H.J. Lu
2024-02-07 16:59                                 ` Jan Beulich
2024-02-07 17:03                                   ` H.J. Lu
2024-02-08  4:09                                     ` Jiang, Haochen
2024-02-08  4:47                                       ` Hongyu Wang
2024-02-08  8:15                                         ` Jan Beulich [this message]
2024-02-08  8:23                                     ` Jan Beulich
2024-02-08 11:38                                       ` H.J. Lu
2024-02-08  6:26                     ` Sunil Pandey
2024-02-08  6:41                   ` Cui, Lili
2024-02-08  8:18                     ` Jan Beulich
2024-02-08 11:31                       ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe4cc5e9-fa24-41ed-ba10-f4bddfc929b4@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=haochen.jiang@intel.com \
    --cc=hjl.tools@gmail.com \
    --cc=matz@suse.de \
    --cc=wwwhhhyyy333@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).