From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, amodra@gmail.com
Subject: Re: [PATCH] powerpc/vdso: Fix incorrect CFI in gettimeofday.S
Date: Mon, 2 May 2022 09:27:05 -0500 [thread overview]
Message-ID: <20220502142705.GU25951@gate.crashing.org> (raw)
In-Reply-To: <20220502125010.1319370-1-mpe@ellerman.id.au>
Hi!
On Mon, May 02, 2022 at 10:50:10PM +1000, Michael Ellerman wrote:
> As reported by Alan, the CFI (Call Frame Information) in the VDSO time
> routines is incorrect since commit ce7d8056e38b ("powerpc/vdso: Prepare
> for switching VDSO to generic C implementation.").
>
> In particular the changes to the frame address register (r1) are not
> properly described, which prevents gdb from being able to generate a
> backtrace from inside VDSO functions, eg:
Note that r1 is not the same as the CFA: r1 is the stack pointer, while
the CFA is a DWARF concept. Often (but not always) they point to the
same thing, for us. "When we change the stack pointer we should change
the DWARF CFA as well"?
> Alan helpfully describes some rules for correctly maintaining the CFI information:
>
> 1) Every adjustment to the current frame address reg (ie. r1) must be
> described, and exactly at the instruction where r1 changes. Why?
> Because stack unwinding might want to access previous frames.
> 2) If a function changes LR or any non-volatile register, the save
> location for those regs must be given. The cfi can be at any
> instruction after the saves up to the point that the reg is
> changed. (Exception: LR save should be described before a bl.)
That isn't an exception? bl changes the current LR after all :-)
> 3) If asychronous unwind info is needed then restores of LR and
> non-volatile regs must also be described. The cfi can be at any
> instruction after the reg is restored up to the point where the
> save location is (potentially) trashed.
The general rule is that your CFI must enable a debugger to reconstruct
the state at function entry (or it can explicitly say something has been
clobbered), using only data available at any point in the program we are
at now. If something is available in multiple places (in some
registers, somewhere in memory) either place can be used; only one such
place is described in the CFI. A store or even a restore does not have
to be described at the exact spot it happens (but that is by far the
most readable / least confusing way to do it).
> --- a/arch/powerpc/kernel/vdso/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso/gettimeofday.S
> @@ -22,12 +22,15 @@
> .macro cvdso_call funct call_time=0
> .cfi_startproc
> PPC_STLU r1, -PPC_MIN_STKFRM(r1)
> + .cfi_adjust_cfa_offset PPC_MIN_STKFRM
> mflr r0
> - .cfi_register lr, r0
> PPC_STLU r1, -PPC_MIN_STKFRM(r1)
> + .cfi_adjust_cfa_offset PPC_MIN_STKFRM
> PPC_STL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1)
> + .cfi_rel_offset lr, PPC_MIN_STKFRM + PPC_LR_STKOFF
So you don't need to describe lr being saved in r0, because at all times
it is available elsewhere, namely in the lr reg still, or on the stack.
If lr could be clobbered before r0 is saved to the stack slot you would
still need to describe r0 containing the value of lr at function entry,
because that value then isn't available elsewhere.
The patch looks good to me :-)
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
next prev parent reply other threads:[~2022-05-02 14:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 12:50 [PATCH] powerpc/vdso: Fix incorrect CFI in gettimeofday.S Michael Ellerman
2022-05-02 14:27 ` Segher Boessenkool [this message]
2022-05-02 23:53 ` Alan Modra
2022-05-04 12:34 ` Michael Ellerman
2022-05-04 12:27 ` Michael Ellerman
2022-05-04 14:08 ` Segher Boessenkool
2022-05-08 11:11 ` Michael Ellerman
2022-05-17 7:33 ` Naveen N. Rao
2022-05-17 12:32 ` Michael Ellerman
2022-05-18 9:38 ` Naveen N. Rao
2022-05-19 1:30 ` Alan Modra
2022-05-20 12:14 ` Naveen N. Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220502142705.GU25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=amodra@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).