Hi LLDB devs,<div><br></div><div>I'm porting LLDB to work with our existing simulator(has a GDB stub, remote debugging, embedded system).</div><div><br></div><div>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!</div><div><br></div><div>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):</div><div><img src="cid:32FEF111@1F439B67.21F8C45E" alt=""></div><div><br></div><div>I found that there are several threads created by lldb:</div><div><img src="cid:2E00ED13@59FCAE4E.21F8C45E" alt=""></div><div>The main process 'lldb' just sends a single 's' packet, but other threads(seems to be 'intern-state') keep sending 's'.</div><div><br></div><div>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:</div><div><img src="cid:3101ED11@994CDD64.21F8C45E" alt=""><br></div><div>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.<br></div><div>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......</div><div><br></div><div>My questions:</div><div>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 : <img src="cid:3106EE0F@130DAC6F.21F8C45E" alt=""> , ignoring the frame which I haven't implemented yet. Perhaps this is the potential reason?)</div><div>*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'?<br></div><div><br>Kind regards,</div><div>Rui</div><div><br></div>