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

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

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.