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: Sun, 11 Oct 2020 22:35:35 -0400

 On Sun, 11 Oct 2020 at 21:18, Nikhil Benesch <nikhil.benesch%gmail.com@localhost> wro=
 te:
 >
 > Sure thing! I can see if that works later tonight.
 >
 > One thing jumps out at me, though: it doesn't seem valid to redefine the =
 CFA like that? As I understand it, the CFA on amd64 is defined to be the st=
 ack pointer in the caller's frame at the time of the call, and you're not a=
 llowed to define it otherwise. The reason to use multiple .cfi_def_cfa dire=
 ctives in one function would be to update the CFA *computation* to account =
 for changes to the variables used in the computation (e.g. RSP), but not to=
  actually change the CFA itself.
 
 Now you've gone and made me read the manual :-( :-)
 
 6.4 Call Frame Information
 =E2=80=A2 An area of memory that is allocated on a stack called a =E2=80=9C=
 call
 frame.=E2=80=9D The call frame is identified by an address on the stack. We
 refer to this address as the Canonical Frame Address or CFA.
 Typically, the CFA is defined to be the value of the stack pointer at
 the call site in the previous frame (which may be different from its
 value on entry to the current frame).
 
 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).
 
 > That said, it's possible that changing the CFA as you propose works just =
 fine in practice. Someone more knowledgeable than me would be better equipp=
 ed to say for sure.
 >
 > I should note that I am far from an expert on this topic. Everything I kn=
 ow about unwind tables has been pieced together in the last two days while =
 trying to fix this gccgo test.
 >
 > On Sun, Oct 11, 2020 at 8:46 PM Kamil Rytarowski <kamil%netbsd.org@localhost> wrote=
 :
 >>
 >> On 12.10.2020 01:54, kamil%NetBSD.org@localhost wrote:
 >> > Synopsis: Unwind tables for signal trampoline on amd64 are incorrect
 >> >
 >> > Responsible-Changed-From-To: lib-bug-people->kamil
 >> > Responsible-Changed-By: kamil%NetBSD.org@localhost
 >> > Responsible-Changed-When: Mon, 12 Oct 2020 01:54:22 +0200
 >> > Responsible-Changed-Why:
 >> > Take.
 >> >
 >> >
 >> >
 >>
 >> We ended up with something like this, but ran out of time:
 >>
 >> http://netbsd.org/~kamil/patch-00283-amd64-__sigtramp2-cfi-unwinding.txt
 >>
 >> Could you please check this code?
 >>
 >> This approach was proposed/inspired by Andrew Cagney and written by myse=
 lf.
 >>
 >> We could combine this with the genassym.cf approach.
 >>