[lldb-dev] LLDB single-stepping problem on remote debugging

[Rui Hong via lldb-dev]

Hi LLDB devs,

I'm porting LLDB to work with our existing simulator(has a GDB stub, remote debugging, embedded system).


Refering to my previous problems about loading binary to remote simulator, it has been solved. The problem was mainly on our compiler which did not generate an executable ELF but just a relocatable file, so it didn't have any (PT_LOAD)segments. And the compiler didn't generate proper DWARF sections as well. Thanks for your great advice!


Now breakpoint and continue function well, but problem occurs on single stepping. When I press 's' on the lldb side, the program(1 process 1 thread) won't stop : lldb keep sending 's' packet to the stub. Like this(listing all RSP packet exchange):



I found that there are several threads created by lldb:

The main process 'lldb' just sends a single 's' packet, but other threads(seems to be 'intern-state') keep sending 's'.


I use GDB to debug my lldb. I found the location that handles single-stepping : ProcessGDBRemote::DoResume() in ProcessGDBRemote.cpp. So I set a breakpoint here, press 's' in lldb and let lldb to be stopped here twice. Everytime the breakpoint get hit, I press 'bt' to print the call stack. The picture:


So you can see the first and second hit's call stack differs(later hits are the same as the second hit). There is a "thread switching" between the first and second hit. The first hit is in the main lldb process and the later hits happens in another thread.

Actually I have found the "stuck point" : lldb get stuck in the while (!exit_now) loop in Process::RunPrivateStateThread in Process.cpp. It can not get out of the while (!exit_now) loop so keep sending 's' packet. I have also found that after the main lldb process finishes sending the first 's', it returns to IOHandlerEditline::Run() in IOHandler.cpp, going into 'GetLine' to wait for the next lldb command to be handled, seems to be nice but other threads keep sending 's' at the same time......


My questions:
1. Why is this happening? Why the lldb keep sending 's', any solutions or hints? (Now when remote program gets stopped, my lldb can't return to "normal" : when I press lldb command there is no "(lldb)" showing on the left. You can see that from the above pictures, like this :  , ignoring the frame which I haven't implemented yet. Perhaps this is the potential reason?)
*2. A single-stepping question that I have been interested in since I started working on debug system but not related to the above problem : what's the implement difference between command 'n'(going through functions) and 's'(going into functions) while there is only one RSP single-step packet named 's'?


Kind regards,
Rui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200520/9d85d07e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3106EE0F at 130DAC6F.21F8C45E.jpg
Type: image/jpeg
Size: 2079 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200520/9d85d07e/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3101ED11 at 994CDD64.21F8C45E.jpg
Type: image/jpeg
Size: 158221 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200520/9d85d07e/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E00ED13 at 59FCAE4E.21F8C45E.jpg
Type: image/jpeg
Size: 17250 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200520/9d85d07e/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32FEF111 at 1F439B67.21F8C45E.jpg
Type: image/jpeg
Size: 47265 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200520/9d85d07e/attachment-0007.jpg>