From: Will Deacon <will@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel-team@android.com,
maz@kernel.org
Subject: Re: [GIT PULL] arm64 updates for 6.2
Date: Tue, 13 Dec 2022 12:52:20 +0000 [thread overview]
Message-ID: <20221213125219.GC5719@willie-the-truck> (raw)
In-Reply-To: <CAMj1kXFf0CYxL28T65WxXUbTwZHJET5Az+oDSxO04zsvkJqwSw@mail.gmail.com>
On Tue, Dec 13, 2022 at 01:36:09PM +0100, Ard Biesheuvel wrote:
> On Tue, 13 Dec 2022 at 13:11, Will Deacon <will@kernel.org> wrote:
> > Ard -- do you think we could tweak the patching so that we patch the push
> > and the pop together (e.g. by tracking the two locations on a per-frame
> > basis and postponing the text poking until just before we return from
> > scs_handle_fde_frame())?
> >
>
> The push and the pop are not necessarily balanced (there may be more
> than one pop for each push), and the opcode we look for
> (DW_CFA_negate_ra_state) may occur in places which are not actually a
> pop, so tracking these is not as straight-forward as this.
Duh, yes, of course. You only _execute_ one of the pops for a given run
through the function, but there could be numerous return points. So my
idea doesn't work at all :)
> What we could do is track the push and the first pop on a first pass,
> and if we don't encounter any unexpected opcodes, patch the push and
> do a second pass starting from the first pop. Or just simply run it
> twice and do no patching the first time around (the DWARF frames are
> not very big)
Doing a dry-run first sounds fairly easy to implement, so it would probably
be a good starting point. It also means that if anybody complains about the
overhead, then we can get them to work on doing it at build time instead!
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-13 12:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 11:25 [GIT PULL] arm64 updates for 6.2 Will Deacon
2022-12-12 18:05 ` Linus Torvalds
2022-12-13 12:11 ` Will Deacon
2022-12-13 12:36 ` Ard Biesheuvel
2022-12-13 12:52 ` Will Deacon [this message]
2022-12-12 18:07 ` pr-tracker-bot
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=20221213125219.GC5719@willie-the-truck \
--to=will@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=torvalds@linux-foundation.org \
/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