From: Will Deacon <will@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Tamas Zsoldos <tamas.zsoldos@arm.com>,
Mark Brown <broonie@kernel.org>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
Daniel Kiss <daniel.kiss@arm.com>
Subject: Re: [PATCH v2 2/2] arm64: vdso: Fix CFI directives in sigreturn trampoline
Date: Wed, 20 May 2020 10:50:28 +0100 [thread overview]
Message-ID: <20200520095027.GE24293@willie-the-truck> (raw)
In-Reply-To: <20200520094212.GK5031@arm.com>
On Wed, May 20, 2020 at 10:42:13AM +0100, Dave Martin wrote:
> On Tue, May 19, 2020 at 05:28:21PM +0100, Will Deacon wrote:
> > @@ -14,7 +18,34 @@
> >
> > .text
> >
> > - nop
> > +/* Ensure that the mysterious NOP can be associated with a function. */
> > + .cfi_startproc
> > +
> > +/*
> > + * .cfi_signal_frame causes the corresponding Frame Description Entry in the
> > + * .eh_frame section to be annotated as a signal frame. This allows DWARF
> > + * unwinders (e.g. libstdc++) to implement _Unwind_GetIPInfo(), which permits
> > + * unwinding out of the signal trampoline without the need for the mysterious
> > + * NOP.
> > + */
> > + .cfi_signal_frame
> > +
> > +/*
> > + * Tell the unwinder where to locate the frame record linking back to the
> > + * interrupted context.
> > + */
> > + .cfi_def_cfa x29, 0
> > + .cfi_offset x29, 0 * 8
> > + .cfi_offset x29, 1 * 8
>
> We should also give rationale for why we don't describe how to recover
> other regs here. At a signal, every reg is potentially live with data
> essential to the backtrace, so custom unwind entries further up the
> stack may unwind badly after trying to unwind out of the signal handler.
Hmm, I'm not sure I get what you're asking for. We can't recover the other
registers even if we tried, can we? I think the only way to get a reliable
backtrace here is not to clobber the framepointer.
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:[~2020-05-20 9:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 16:28 [PATCH v2 0/2] arm64 sigreturn unwinding fixes Will Deacon
2020-05-19 16:28 ` [PATCH v2 1/2] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction Will Deacon
2020-05-19 16:33 ` Mark Brown
2020-05-20 9:33 ` Dave Martin
2020-05-20 9:53 ` Will Deacon
2020-05-19 16:28 ` [PATCH v2 2/2] arm64: vdso: Fix CFI directives in sigreturn trampoline Will Deacon
2020-05-20 9:42 ` Dave Martin
2020-05-20 9:50 ` Will Deacon [this message]
2020-05-20 10:27 ` Dave Martin
2020-05-20 10:36 ` Will Deacon
2020-05-20 11:03 ` Dave Martin
2020-05-20 10:48 ` Will Deacon
2020-05-20 11:06 ` Dave Martin
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=20200520095027.GE24293@willie-the-truck \
--to=will@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=broonie@kernel.org \
--cc=daniel.kiss@arm.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=tamas.zsoldos@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.