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

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

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

From: Andrew Cagney <andrew.cagney%gmail.com@localhost>
To: Nikhil Benesch <nikhil.benesch%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: Mon, 12 Oct 2020 01:02:29 -0400

 On Sun, 11 Oct 2020 at 23:30, 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.
 
 The other thing to keep in mind is that this is for signal trampolines
 which are outside the scope of DWARF.
 
 > 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.
 
 Code uses the tuple {CFA,FUNCTION_START} to identify a frame.  So if
 the CFA changes, code will think the frame changed.
 
 Testing is "easy".  Code up a SIGILL, say, and then breakpoint on the
 signal handler.  Then instruction-step back to the trapping
 instruction.  Every single instruction needs to breaktrace correctly.
 GDB should still have tests (I wrote) that do this.
 
 > 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.
 
 You mean the non-normative text in: Call Frame Calling Address where
 it discusses the hack of subtracting 1 from the return address?
 
 + * The unwind entry includes the one byte prior to the trampoline
 + * because the unwinder will look up (return PC - 1) while unwinding.
 + * Normally (return PC - 1) computes an address inside the call
 + * instruction that created the child frame, but here there is no call
 + * instruction so we have to manually add padding.
 
 yep.
 
 Is the PC-1 hack also used when looking up the sigtramp's [elf] symbol
 (I don't remember)?  Just look at the backtrace out of the signal
 handler.
 
 >
 > Also apologies that my last mail was sent in HTML, not plain text.
 > That should be fixed now.
 
 It's 2020.  Personally I don't care.
 
 > [0]: https://www.corsix.org/content/cfa-rsp-x86-64