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),
// Our Call Frame Address is the stack pointer value
row->GetCFAValue().SetIsRegisterPlusOffset(dwarf_r29, 0);
The default unwind plan says to find the caller's pc value in $r31,
// The previous PC is in the RA
row->SetRegisterLocationToRegister(dwarf_pc, dwarf_r31, true);
unwind_plan.AppendRow(row);
which is fine for frame 0, we can look at $r31, but as soon as we move off of
frame 0, we have to find the saved $r31 value on the stack (frame 0 had to
spill it to the stack, right).
Unfortunately we don't have the function bounds of frame 0, we only have the
architectural default unwind plan. This default unwind plan cannot do the
right thing except on frame 0.
On other architectures where a return address register is used, like arm, the
default unwind plan assumes that the pc and saved frame pointer have been
spilled to stack, and there is a convention that they're the first two things
spilled to stack. So we see in ABISysV_arm::CreateDefaultUnwindPlan,
row->SetRegisterLocationToAtCFAPlusOffset(fp_reg_num, ptr_size * -2, true);
row->SetRegisterLocationToAtCFAPlusOffset(pc_reg_num, ptr_size * -1, true);
We also have a ABISysV_arm::CreateFunctionEntryUnwindPlan unwind plan that is
guaranteed to be valid at the first instruction of a function; it says that the
saved PC is in the return address register,
// Our Call Frame Address is the stack pointer value
row->GetCFAValue().SetIsRegisterPlusOffset(sp_reg_num, 0);
// The previous PC is in the LR
row->SetRegisterLocationToRegister(pc_reg_num, lr_reg_num, true);
unwind_plan.AppendRow(row);
although I should warn that I'm 99% sure that "nexti" doesn't currently record
the fact that it is potentially stepping into a function, so lldb doesn't know
to use the FunctionEntryUnwindPlan. We prob should.
fwiw the 0x value is lldb's LLDB_INVALID_ADDRESS.
J
> On Jan 27, 2020, at 10:43 AM, 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 to get the register values it needs, and I wasn't including them in
> my qRegisterInfo responses. After fixing this, step over and step out appear
> to work correctly, which is a great help.
>
> However, backtraces only show 2 frames with the current pc and ra values, no
> matter where I am, so it seems there's some problem getting stack frame info
> from the actual stack. I've attached an unwind log from running bt inside a
> function that should have a deeper backtrace. The afa value of
> 0x looks suspicious to me, but I don't really understand
> where it comes from. The frame before 0x8002ee70 should, I think, be
> 0x80026a6c, as that's the pc after stepping out twice.
>
> Thanks,
> Alexander
>
> On Sun, Jan 26, 2020 at 4:21 PM Jason Molenda wrote:
> 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
> show-unwind -a $pc'. I don't know what unwinders we have defined for this
> target in lldb right now -- if you have eh_frame information in your binary,
> lldb should read & use that. Otherwise, if you have an assembly instruction
> profiler in lldb for mips, and start addresses for your functions, lldb
> should be able to inspect the instruction stream and figure out how to unwind
> out of the function correctly. As a last resort, it will fall back to
> architecture rules for how to backtrace out of a function (defined in the ABI
> plugin) but those are often incorrect in prologue/epilogues (start & end of a
> function).
>
>
>
> (btw if you support no-ack mode, there's a lot less packet traffic between
> your stub and lldb - recommended.)
>
>
> J
>
>
>
>
> > On Jan 25, 2020, at 3:08 PM, Alexander Zhang via lldb-dev
> > wrote:
> >
> > 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?
> > I've attached some communication logs, and if it helps my code is at
> > https://github.com/CQCumbers/nmulator/blob/master/src/debugger.h
> >
> > Please forgive me if this isn't the right
