Re: Restoring pc to a different value than lr on aarch64

> > 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.

I agree the current code makes sense for what gcc generates. However,
I think given the document from arm, explicitly setting the PC value
in the unwind info should also work.
Would a patch similar to the one above be acceptable to fix this issue?

A related issue is that gdb also seems to be ignoring the return
address register in CIE. There is at least one use of it in glibc[2]
where the return address register is set to x15 instead.
I've verified that gdb is currently unable to unwind after the call to
`strlen` from `rawmemchr` even though the return address is still in
x15.
I thought this can be fixed by chaiming that PC is RA just like the
fallback case but that is apparently not working...

[2] https://github.com/bminor/glibc/blob/b92a49359f33a461db080a33940d73f47c756126/sysdeps/aarch64/rawmemchr.S#L34

> >>
> >> 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
>