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

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

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