All of lore.kernel.org
 help / color / mirror / Atom feed
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" <kernel-team@android.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Daniel Kiss <Daniel.Kiss@arm.com>
Subject: Re: [PATCH 3/3] arm64: vdso: Fix CFI directives in sigreturn trampoline
Date: Tue, 19 May 2020 16:24:54 +0100	[thread overview]
Message-ID: <20200519152453.GA15811@willie-the-truck> (raw)
In-Reply-To: <20200519135537.GG5031@arm.com>

On Tue, May 19, 2020 at 02:55:37PM +0100, Dave Martin wrote:
> On Tue, May 19, 2020 at 02:39:41PM +0100, Will Deacon wrote:
> > The gas docs say:
> > 
> > 	"Mark current function as signal trampoline."
> > 
> > which is really informative.
> 
> Well, we've demonstrated that identifying the signal frame is a gross
> bodge.  The cfi annotation should provide a reliable way to identify the
> signal frame, but I guess it was too poorly specified or came too late
> to prevent the bodges from spreading.
> 
> Since this seems to be a nonstandard invention, I wouldn't hold out
> much hope of finding a usable spec.
> 
> Of course, something might be using it now, so I guess we have to leave
> it.

I had a quick look at libstdc++ (the horror!) and it looks like the DWARF
backend in there /does/ make use of this information as part of the
_Unwind_GetIPInfo() function:

https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib--unwind-getipinfo.html

*ip_before_insn is set to 1 or 0 depending on whether or not the PC
corresponds to a function annotated with .cfi_signal_frame. So I think
the code in libstdc++-v3/libsupc++/eh_personality.cc doesn't need the
mysterious NOP at all!

Unfortunately, it looks like the LLVM libc++ doesn't use this, and instead
calls _Unwind_GetIP():

https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib--unwind-getip.html

and unconditionally subtracts 1 in libcxxabi/src/cxa_personality.cpp,
meaning that the NOP is necessary.

So, after giving myself a splitting headache, it looks like:

  1. We need the mysterious NOP for LLVM
  2. We could drop .cfi_signal_frame but it's harmless to keep it
  3. We need the .cfi_def_cfa directive to locate the frame record, as
     .cfi_signal_frame doesn't do very much at all.

Make sense? If so, I'll spin a v2 of the patches along with a comment
trying to summarise some of this.

Cheers,

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-05-19 15:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 12:18 [PATCH 0/3] arm64 sigreturn unwinding fixes Will Deacon
2020-05-19 12:18 ` [PATCH 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction Will Deacon
2020-05-19 12:38   ` Mark Brown
2020-05-19 13:25     ` Dave Martin
2020-05-19 14:35       ` Mark Brown
2020-05-19 14:55         ` Dave Martin
2020-05-19 15:42           ` Mark Brown
2020-05-20  9:48             ` Dave Martin
2020-05-20 10:46               ` Mark Brown
2020-05-20 11:08                 ` Dave Martin
2020-05-19 15:26     ` Will Deacon
2020-05-19 13:21   ` Dave Martin
2020-05-19 13:29     ` Will Deacon
2020-05-19 12:18 ` [PATCH 2/3] arm64: vdso: Add a comment to justify the mysterious NOP in sigreturn Will Deacon
2020-05-19 13:26   ` Dave Martin
2020-05-19 12:18 ` [PATCH 3/3] arm64: vdso: Fix CFI directives in sigreturn trampoline Will Deacon
2020-05-19 13:09   ` Dave P Martin
2020-05-19 13:39     ` Will Deacon
2020-05-19 13:55       ` Dave Martin
2020-05-19 15:24         ` Will Deacon [this message]
2020-05-19 15:30         ` Daniel Kiss
2020-05-19 15:55           ` Will Deacon

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=20200519152453.GA15811@willie-the-truck \
    --to=will@kernel.org \
    --cc=Daniel.Kiss@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Tamas.Zsoldos@arm.com \
    --cc=broonie@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.