Hi Alexander, sorry for the delay in replying.
The attached unwind log shows that lldb is using the architectural default
unwind plan for this target. You can see where this unwind plan in constructed
at
ABISysV_mips::CreateDefaultUnwindPlan
it says to find the caller's pc value at *($r29),
On 27/01/2020 19:43, Alexander Zhang via lldb-dev wrote:
> Hi,
>
> Thanks for pointing me towards stack unwinding. I don't have debug
> information much of the time, so I'm depending on the architecture rules
> for backtracing. A look at the mips ABI plugin shows it uses dwarf
> register numbers t
Hi,
Thanks for pointing me towards stack unwinding. I don't have debug
information much of the time, so I'm depending on the architecture rules
for backtracing. A look at the mips ABI plugin shows it uses dwarf register
numbers to get the register values it needs, and I wasn't including them in
my
I suspect your problem may be related to lldb not knowing how to walk the stack
on this target. Is mips-unknown-linux-gnu correct? What do you see if you
turn on unwind logging, 'log enable lldb unwind'. You can also have lldb show
you the unwind rules at the current pc value with 'image sho
Hi,
I've been implementing a basic RSP protocol server for remotely debugging a
MIPS simulator, and have been having some trouble getting certain lldb
features to work there, in particular backtraces (bt) and instruction step
over (ni). Does someone know what packets these commands rely on to work
