<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Alexander </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 26, 2020 at 4:21 PM Jason Molenda <<a href="mailto:jason@molenda.com" target="_blank">jason@molenda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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).<br>
<br>
<br>
<br>
(btw if you support no-ack mode, there's a lot less packet traffic between your stub and lldb - recommended.)<br>
<br>
<br>
J<br>
<br>
<br>
<br>
<br>
> On Jan 25, 2020, at 3:08 PM, Alexander Zhang via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> 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 <a href="https://github.com/CQCumbers/nmulator/blob/master/src/debugger.h" rel="noreferrer" target="_blank">https://github.com/CQCumbers/nmulator/blob/master/src/debugger.h</a><br>
> <br>
> 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.<br>
> <br>
> Also, just a user question, but is there a way to show register values in hex format without leading zeros?<br>
> <br>
> Thanks,<br>
> Alexander<br>
> <packets.txt>_______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>