[lldb-dev] Unwinding call frames with separated data and return address stacks

Pavel Labath via lldb-dev lldb-dev at lists.llvm.org
Tue Mar 5 03:56:12 PST 2019

On 04/03/2019 11:46, Thomas Goodfellow via lldb-dev wrote:
> I'm adding LLDB support for an unconventional platform which uses two
> stacks: one purely for return addresses and another for frame context
> (spilled registers, local variables, etc). There is no explicit link
> between the two stacks, i.e. the frame context doesn't include any
> pointer or index to identify the return address: the epilog for a
> subroutine amounts to unwinding the frame context then finally popping
> the top return address from the return stack. It has some resemblance
> to the Intel CET scheme of shadow stacks, but without the primary
> stack having a copy of the return address.
> I can extend the emulation of the platform to better support LLDB. For
> example while the real hardware platform provides no access to the
> return address stack the emulation can expose it in the memory map,
> provide an additional debug register for querying it, etc, which DWARF
> expressions could then extract return addresses from. However doing
> this seems to require knowing the frame number and I haven't found a
> way of doing this (a pseudo-register manipulated by DWARF expressions
> worked but needed some LLDB hacks to sneak it through the existing
> link register handling, also seemed likely to be unstable against LLDB
> implementation changes)
> Is there a way to access the call frame number (or a reliable proxy)
> from a DWARF expression? Or an existing example of unwinding a shadow
> stack?

I'm not sure I fully understood your setup, but it seems to me that this 
could be easily fixed if, in addition to the "fake" memory map, you 
could provide a fake "stack pointer" register which points to it.

Then, it should be possible to express the unwind info in regular 
debug_frame syntax:
previous_IP := [ fake_SP ]
previous_fake_SP := fake_SP +/- sizeof(IP)


More information about the lldb-dev mailing list