From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Julien Thierry <jthierry@redhat.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
mbenes@suse.cz, raphael.gault@arm.com, benh@kernel.crashing.org
Subject: Re: [PATCH v2 9/9] objtool: Abstract unwind hint reading
Date: Mon, 31 Aug 2020 14:55:46 -0500 [thread overview]
Message-ID: <20200831195546.gt72y5tplwuftqv7@treble> (raw)
In-Reply-To: <8fe8199e-a2f3-513f-6cdf-c61d7936dede@redhat.com>
On Tue, Aug 25, 2020 at 01:31:46PM +0100, Julien Thierry wrote:
> > > > The call to update_cfi_state_regs() is really regs-specific, not
> > > > sp-specific.
> > > >
> > >
> > > I must admit I don't really understand what "regs" is and why exactly such
> > > an exception in stack state tracking is made where only operations to SP are
> > > taken into account.
> >
> > "regs" is a special type of stack frame, usually for asm entry code,
> > where the frame is actually an instance of 'struct pt_regs'. So if
> > there's a variable associated it with it, maybe it should have "regs" in
> > the name.
> >
> > Though I think non-x86 arches will also have regs frames, so would it
> > make sense to just make the unwind hint types a global multiarch thing?
> > They could be renamed to UNWIND_HINT_TYPE_REGS{_PARTIAL}. Then there
> > wouldn't really be a need for the "sp_only" thing.
> >
>
> If having regs frame means having a pt_regs on the stack when procedure
> calls/return, then yes this will probably be the case on most archs (it is
> for arm64 at least.
The regs frames aren't for function/procedure calls, but rather
exceptions/interrupts.
> However in that case, arm64 still builds a stack frame and sets the frame
> pointer, so only handling SP operations doesn't make much sense for arm64.
If for example arm64 were to switch to ORC, it could have regs-only
frames in entry code just like x86.
> Also, things like ORC_TYPE_REGS_IRET don't have a use for arm64 (but maybe
> for other non-x86 arches it does?)
If we called it TYPE_REGS_PARTIAL, at least the name would be generic
enough, even if it's not used by all arches.
> In the end that's why I left the unwind hint types as arch defined. It seems
> like every arch will have their specific semantics they might want to let
> objtool know about.
Ok, I guess I'd need to look at the code to have an opinion. If there
turn out to be commonalities between the different arch unwind hints
then we could always unify them later.
--
Josh
next prev parent reply other threads:[~2020-08-31 19:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 9:46 [PATCH v2 0/9] Make check implementation arch agnostic Julien Thierry
2020-07-30 9:46 ` [PATCH v2 1/9] objtool: Group headers to check in a single list Julien Thierry
2020-07-30 9:46 ` [PATCH v2 2/9] objtool: Make sync-check consider the target architecture Julien Thierry
2020-07-30 9:46 ` [PATCH v2 3/9] objtool: Move macros describing structures to arch-dependent code Julien Thierry
2020-07-30 9:46 ` [PATCH v2 4/9] objtool: Abstract alternative special case handling Julien Thierry
2020-07-30 9:46 ` [PATCH v2 5/9] objtool: Make relocation in alternative handling arch dependent Julien Thierry
2020-07-30 14:42 ` Josh Poimboeuf
2020-07-31 7:24 ` Julien Thierry
2020-07-30 9:46 ` [PATCH v2 6/9] objtool: Refactor switch-tables code to support other architectures Julien Thierry
2020-07-30 9:46 ` [PATCH v2 7/9] frame: Only include valid definitions depending on source file type Julien Thierry
2020-07-30 9:46 ` [PATCH v2 8/9] frame: Make unwind hints definitions available to other architectures Julien Thierry
2020-07-30 14:56 ` Josh Poimboeuf
2020-08-25 12:12 ` Julien Thierry
2020-08-31 18:31 ` Josh Poimboeuf
2020-07-30 9:46 ` [PATCH v2 9/9] objtool: Abstract unwind hint reading Julien Thierry
2020-07-30 15:03 ` Josh Poimboeuf
2020-07-31 7:00 ` Julien Thierry
2020-07-31 14:04 ` Josh Poimboeuf
2020-08-03 12:13 ` Julien Thierry
2020-08-03 21:35 ` Josh Poimboeuf
2020-08-25 12:31 ` Julien Thierry
2020-08-31 19:55 ` Josh Poimboeuf [this message]
2020-07-30 12:38 ` [PATCH v2 0/9] Make check implementation arch agnostic peterz
2020-07-31 9:14 ` Miroslav Benes
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=20200831195546.gt72y5tplwuftqv7@treble \
--to=jpoimboe@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=jthierry@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=peterz@infradead.org \
--cc=raphael.gault@arm.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
all inboxes | Powered by JetHome®