public inbox for
 help / color / mirror / Atom feed
From: Yichao Yu <>
Subject: Re: Restoring pc to a different value than lr on aarch64
Date: Fri, 6 May 2022 08:46:32 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, May 6, 2022 at 8:05 AM Yichao Yu <> wrote:
> I have a case in my code where I want to restore the value of lr (x30)
> during unwinding, to a different value than the return address of the
> code. However, it seems that for aarch64,
> (aarch64_dwarf2_frame_init_reg among other functions) hardcode x30 and
> pc to be exactly the same value after unwinding.

Actually I misspoke for that. It seems that sp is probably fine and
the only thing missing causing pc to not work is that
aarch64_dwarf_reg_to_regnum doesn't understand the PC dwarf reg
number. It seems that the only thing needed is to add a

+  if (reg == AARCH64_DWARF_PC)
+    return AARCH64_PC_REGNUM;

to that function.

> According to aadwarf64[1],
> > having both LR and PC columns is useful for describing asynchronously created stack frames. A DWARF expression may use this register to restore the context in case of a signal context.
> so assume the intention is that if I explicitly unwind the pc in
> addition to lr, it should work. I tried to do that, and also to set
> return address column to 32, as well as trying to mark the frame as
> signal frame but none of them seems to work. Is there any way for gdb
> to honer the explicit unwinding of pc?
> Also it seems that the sp is also card coded to be cfa. My code also
> contains explicit saving and restoring of that as well so if that's
> the case (haven't tested yet) it would be a problem too...
> Would it be possible to not use this hard-coded logic if the frame
> contains explicit override of the pc value?
> Yichao
> A bit more about the actual code. This is done as part of runtime
> patching code. The actual restoration of lr is done by returning to a
> runtime allocated stub that restores lr and directly branch back to
> the return location. After returning, all registers values are
> restored back to their previous one. The stack pointer is also
> switched out since we cannot rely on how much stack space the call
> site has available.
> [1]

  reply	other threads:[~2022-05-06 12:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 12:05 Yichao Yu
2022-05-06 12:46 ` Yichao Yu [this message]
2022-05-06 13:32   ` Luis Machado
2022-05-06 16:11     ` Yichao Yu
2022-05-06 16:30       ` Yichao Yu
2022-05-09 10:44         ` Luis Machado
2022-05-09 14:24           ` Yichao Yu
2022-05-10 14:48             ` Luis Machado
2022-05-11 13:26               ` Yichao Yu
2022-05-11 14:51                 ` Luis Machado
2022-05-11 15:10                   ` Luis Machado
2022-05-13 12:34                   ` Yichao Yu

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

* 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 read-only IMAP folder(s) and NNTP newsgroup(s).