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: gnats-bugs%netbsd.org@localhost
Cc: kamil%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/55719 (Unwind tables for signal trampoline on amd64 are incorrect)
Date: Mon, 12 Oct 2020 01:57:32 -0400

 On Mon, Oct 12, 2020 at 1:05 AM Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
 >  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.
 
 Via reverse-debugging, yeah? I couldn't get this to work in the GDB
 that ships with NetBSD.
 
 (gdb) target record-full
 Process record: the current architecture doesn't support record function.
 
 Possibly due to the fact that I'm using a VM? Not sure.
 
 >  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.
 
 Looks the same to me in GDB with and without this patch. The signal
 handler frame is labeled as "<signal handler called>".
 
 #0  sig_handler (no=11) at main.c:7
 #1  <signal handler called>
 #2  0x0000000000400bd8 in f1 (x=42, y=0x0) at main.c:12
 #3  0x0000000000400c35 in main () at main.c:23
 
 >  > 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.
 
 GNATS seems to be stuck in 2004 and renders multipart emails terribly.