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

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

The following reply was made to PR lib/55719; it has been noted by GNATS.

From: Nikhil Benesch <nikhil.benesch%gmail.com@localhost>
To: Andrew Cagney <andrew.cagney%gmail.com@localhost>
Cc: Kamil Rytarowski <kamil%netbsd.org@localhost>, gnats-bugs%netbsd.org@localhost, lib-bug-people%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	=?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny%netbsd.org@localhost>
Subject: Re: lib/55719 (Unwind tables for signal trampoline on amd64 are incorrect)
Date: Sun, 11 Oct 2020 23:30:00 -0400

 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