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

[Kamil Rytarowski <kamil%netbsd.org@localhost>]

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

From: Kamil Rytarowski <kamil%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost, kamil%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, nikhil.benesch%gmail.com@localhost,
 Andrew Cagney <andrew.cagney%gmail.com@localhost>
Cc: 
Subject: Re: lib/55719 (Unwind tables for signal trampoline on amd64 are
 incorrect)
Date: Mon, 12 Oct 2020 16:01:01 +0200

 On 12.10.2020 08:00, Nikhil Benesch wrote:
 > 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.
 >  
 > 
 
 Nikhil, great work! This code works!
 
 http://netbsd.org/~kamil/backtrace/libc-x86_64-PR55719.txt
 
 Andrew, is this ready to commit?
 
 http://netbsd.org/~kamil/patch-00283-amd64-__sigtramp2-cfi-unwinding.2.txt