[lldb-dev] gdb-remote protocol questions

[Alexander Zhang via lldb-dev]

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
0xffffffffffffffff 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 <jason at molenda.com> 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 <
> lldb-dev at lists.llvm.org> 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 place to ask - I know this
> isn't directly part of lldb development but I've tried several other places
> and haven't been able to find anyone familiar with the subject.
> >
> > Also, just a user question, but is there a way to show register values
> in hex format without leading zeros?
> >
> > Thanks,
> > Alexander
> > <packets.txt>_______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200127/a55d1d2f/attachment.html>
-------------- next part --------------
(lldb) bt
 th1/fr0 supplying caller's saved pc (37)'s location, cached
  th1/fr1 pc = 0x8002ee70
 th1/fr0 supplying caller's saved r30 (30)'s location, cached
  th1/fr1 fp = 0x8004e750
 th1/fr0 supplying caller's saved r29 (29)'s location, cached
  th1/fr1 sp = 0x8004e750
  th1/fr1 using architectural default unwind method
 th1/fr0 supplying caller's saved r29 (29)'s location, cached
  th1/fr1 CFA is 0x8004e750: Register r29 (29) contents are 0x8004e750, offset is 0
  th1/fr1 initialized frame cfa is 0x8004e750 afa is 0xffffffffffffffff
 th1/fr0 supplying caller's saved pc (37)'s location, cached
  th1/fr1 supplying caller's saved pc (37)'s location using mips default unwind plan UnwindPlan
  th1/fr1 mips default unwind plan UnwindPlan tried to restore the pc from the link register but this is a non-zero frame
  th1/fr1 supplying caller's saved pc (37)'s location using ABI default
  th1/fr1 did not supply reg location for pc (37) because it is volatile
   th1/fr2 could not get pc value
   Frame 2 invalid RegisterContext for this frame, stopping stack walk
  th1/fr1 supplying caller's saved pc (37)'s location using mips default unwind plan UnwindPlan
  th1/fr1 mips default unwind plan UnwindPlan tried to restore the pc from the link register but this is a non-zero frame
  th1/fr1 supplying caller's saved pc (37)'s location using ABI default
  th1/fr1 did not supply reg location for pc (37) because it is volatile
   th1/fr2 could not get pc value
   Frame 2 invalid RegisterContext for this frame, stopping stack walk
 th1 Unwind of this thread is complete.
* thread #1, stop reason = instruction step into
  * frame #0: 0x800357c4
    frame #1: 0x8002ee70
(lldb) memory read -a 0x8004e750
0x8004e750: 80 05 d6 a0 00 00 00 fe 00 00 00 01 00 00 00 0a  ..֠...?........
0x8004e760: 00 00 00 02 80 04 e7 70 80 02 6a 6c 80 02 6a 40  ......?p..jl..j@