linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 4 May 2022 09:08:29 -0500	[thread overview]
Message-ID: <20220504140829.GY25951@gate.crashing.org> (raw)
In-Reply-To: <878rrhv5x1.fsf@mpe.ellerman.id.au>

Hi!

On Wed, May 04, 2022 at 10:27:54PM +1000, Michael Ellerman wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > 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"?
>  
> Thanks, I reworded it a bit:
> 
>     DWARF has a concept called the CFA (Canonical Frame Address), which on
>     powerpc is calculated as an offset from the stack pointer (r1). That
>     means when the stack pointer is changed there must be a corresponding
>     CFI directive to update the calculation of the CFA.

The CFA only uses r1 if it does not have a separate frame pointer, in
which case that is used.  "... is usually calculated ..." maybe?  A bit
of handwaving is better than giving the impression you are stating
something exact, if you don't.

> >>   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 :-)
>  
> As Alan mentioned the exception is the the CFI has to appear before the
> bl not after, I noted that in the change log.

You have a bit of freedom where you place your CFI statements, but you
cannot place them too late (or too early).  This is true for all CFI
statements.  I suppose the final consequence of that can be a bit
surprising here :-)


Segher

  reply	other threads:[~2022-05-04 14:12 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
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 [this message]
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=20220504140829.GY25951@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).