public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: [PATCH 1/6] x86: last-insn recording should be per-section
Date: Fri, 24 Nov 2023 14:29:43 +0100	[thread overview]
Message-ID: <8e77668a-48c4-428c-8ef6-4b638fecb514@suse.com> (raw)
In-Reply-To: <94626e2b-0e73-4267-9c80-cb25e1dbab9b@suse.com>

On 24.11.2023 10:03, Jan Beulich wrote:
> Otherwise intermediate section switches result in inconsistent behavior.
> Note, however, that intermediate sub-section switches will continue to
> result in inconsistent or even inappropriate behavior.
> 
> While there also add recording of state to s_insn().
> ---
> i386_cons_align() qualifying the recording on SEC_CODE seems suspicious,
> too: md_assemble() isn't constrained to emitting instructions to only
> text sections.
> 
> For sub-sections the best I can think of that we could do is warn when
> now_subseg is nonzero wherever we already warn based on last_insn state
> (and similarly bail rather than inserting any code). That would have
> not really intended effects in subsequent patches, though: We'd then
> generally suppress optimizations outside of subseg 0, and we'd also
> prefix plain old NOPs there (in i386_generate_nops()).

With some prereq tweaking of (at least) obj-elf.c, perhaps we could leverage
md_elf_section_change_hook() to deal with subsections. The prereq tweaking
would be needed as from my initial investigations I'm getting the impression
that not all section switches actually properly invoke that hook.

Jan

  parent reply	other threads:[~2023-11-24 13:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24  9:02 [PATCH 0/6] correct and further utilize x86'es last-insn tracking Jan Beulich
2023-11-24  9:03 ` [PATCH 1/6] x86: last-insn recording should be per-section Jan Beulich
2023-11-24  9:04   ` [PATCH 3/6] gas: no md_cons_align() for .nop{,s} Jan Beulich
2023-11-24 13:29   ` Jan Beulich [this message]
2023-11-24  9:03 ` [PATCH 2/6] x86: suppress optimization after potential non-insn Jan Beulich
2023-11-24  9:05 ` [PATCH 4/6] x86: i386_cons_align() badly affects diagnostics Jan Beulich
2023-11-24  9:05 ` [PATCH 5/6] x86: adjust NOP generation after potential non-insn Jan Beulich
2023-11-24  9:06 ` [PATCH 6/6] gas: drop unused fields from struct segment_info_struct Jan Beulich

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=8e77668a-48c4-428c-8ef6-4b638fecb514@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@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).