Re: lib/55719 (Unwind tables for signal trampoline on amd64 are incorrect)

[Nikhil Benesch <nikhil.benesch%gmail.com@localhost>]

Ok, I've combined the two approaches like so:

https://gist.githubusercontent.com/benesch/7052d40ed9de9a3a5d3886a060ec3a3d/raw/93abaac2ae83e6b4e63951bd0c44f1100e5e7f0e/netbsd-sigtramp-unwind.patch

The new patch continues to work for gccgo and does so with far less
complexity. I'm quite hopeful that this is now in a mergeable state.

On Sun, Oct 11, 2020 at 11:30 PM Nikhil Benesch
<nikhil.benesch%gmail.com@localhost> wrote:
>
> On Sun, Oct 11, 2020 at 10:35 PM Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
> > So any code wanting the caller's stack pointer will need to parse the
> > CFI and then unwind the stack-pointer (CFA is a convenient fiction
> > invented by DWARF).
> >
> > The only real expectation is that the CFA is constant through out the
> > lifetime of the frame (one of the things identifying  a single-stepped
> > call/return instruction is the changed CFA).
>
> Hmm, ok, so perhaps just picking a different CFA for this frame is
> acceptable then. My assertion that the CFA must be equal to RSP on
> amd64 is based only on this blog post [0], which is hardly
> authoritative.
>
> Kamil's patch as written sets the CFA to both R15 and later (RSP + 8),
> but that is easy enough to fix to drop the second .cfi_def_cfa
> directive. There is still the issue of generating the FDE one PC
> earlier than the beginning of the sigtramp symbol, but maybe I can
> work something out.
>
> Also apologies that my last mail was sent in HTML, not plain text.
> That should be fixed now.
>
> [0]: https://www.corsix.org/content/cfa-rsp-x86-64