From: Luis Machado <luis.machado@arm.com>
To: Yichao Yu <yyc1992@gmail.com>, gdb@sourceware.org
Subject: Re: Restoring pc to a different value than lr on aarch64
Date: Fri, 6 May 2022 14:32:24 +0100 [thread overview]
Message-ID: <257aa215-a141-6d9b-672d-ea8ce209b107@arm.com> (raw)
In-Reply-To: <CAMvDr+SyJUAL=SU=SyLX17giffr-G=MOXdWm9LrF45Fa3we1Hw@mail.gmail.com>
On 5/6/22 13:46, Yichao Yu via Gdb wrote:
> On Fri, May 6, 2022 at 8:05 AM Yichao Yu <yyc1992@gmail.com> 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.
>
Yes, GDB always assumes the PC from the previous frame is the LR from
the current frame. That is what GCC generates.
If a different setup is needed, GDB needs to be taught about it.
>>
>> 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.
This seems to work in a similar way as signal handler. GDB needs to be
taught where to find the registers so it can properly unwind things.
>>
>> [1] https://github.com/ARM-software/abi-aa/blob/8a7b266879c60ca1c76e94ebb279b2dac60ed6a5/aadwarf64/aadwarf64.rst#note-9
next prev parent reply other threads:[~2022-05-06 13:32 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
2022-05-06 13:32 ` Luis Machado [this message]
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:
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=257aa215-a141-6d9b-672d-ea8ce209b107@arm.com \
--to=luis.machado@arm.com \
--cc=gdb@sourceware.org \
--cc=yyc1992@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).