[lldb-dev] gdb-remote protocol questions
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 (lldb) log enable gdb-remote all (lldb) gdb-remote 4343 ProcessGDBRemote::ConnectToDebugserver Connecting to connect://localhost:4343 < 1> send packet: + history[1] tid=0x0307 < 1> send packet: + < 7> read packet: $S05#b8 < 1> send packet: + < 19> send packet: $QStartNoAckMode#b0 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 41> send packet: $qSupported:xmlRegisters=i386,arm,mips#12 < 1> read packet: + < 19> read packet: $PacketSize=2047#fd < 1> send packet: + < 26> send packet: $QThreadSuffixSupported#e4 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 27> send packet: $QListThreadsInStopReply#21 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 13> send packet: $qHostInfo#9b < 1> read packet: + < 61> read packet: $triple:6d6970732d6c696e75782d676e75;ptrsize:8;endian:big;#d1 < 1> send packet: + GDBRemoteCommunicationClient::GetHostInfo parsed host architecture as mips, triple as mips-unknown-linux-gnu from triple text mips-linux-gnu < 10> send packet: $vCont?#49 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 27> send packet: $qVAttachOrWaitSupported#38 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 23> send packet: $QEnableErrorStrings#8c < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + ProcessGDBRemote::StartAsyncThread () < 16> send packet: $qProcessInfo#dc ProcessGDBRemote::AsyncThread (arg = 0x7f8eff006218, pid = 0) thread starting... ProcessGDBRemote::AsyncThread (arg = 0x7f8eff006218, pid = 0) listener.WaitForEvent (NULL, event_sp)... < 1> read packet: + < 46> read packet: $triple:6d6970732d6c696e75782d676e75;pid:1;#e0 < 1> send packet: + < 5> send packet: $?#3f < 1> read packet: + < 7> read packet: $S05#b8 < 1> send packet: + < 18> send packet: $qRegisterInfo0#72 < 1> read packet: + < 57> read packet: $name:r0;bitsize:64;offset:0;encoding:sint;format:hex;#7a < 1> send packet: + < 18> send packet: $qRegisterInfo1#73 < 1> read packet: + < 57> read packet: $name:at;bitsize:64;offset:8;encoding:sint;format:hex;#b5 < 1> send packet: + < 18> send packet: $qRegisterInfo2#74 < 1> read packet: + < 58> read packet: $name:v0;bitsize:64;offset:16;encoding:sint;format:hex;#b5 < 1> send packet: + < 18> send packet: $qRegisterInfo3#75 < 1> read packet: + < 58> read packet: $name:v1;bitsize:64;offset:24;encoding:sint;format:hex;#b5 < 1> send packet: + < 18> send packet: $qRegisterInfo4#76 < 1> read packet: + < 58> read packet: $name:a0;bitsize:64;offset:32;encoding:sint;format:hex;#9e < 1> send packet: + < 18> send packet: $qRegisterInfo5#77 < 1> read packet: + < 58> read packet: $name:a1;bitsize:64;offset:40;encoding:sint;format:hex;#9e < 1> send packet: + < 18> send packet: $qRegisterInfo6#78 < 1> read packet: + < 58> read packet: $name:a2;bitsize:64;offset:48;encoding:sint;format:hex;#a7 < 1> send packet: + < 18> send packet: $qRegisterInfo7#79 < 1> read packet: + < 58> read packet: $name:a3;bitsize:64;offset:56;encoding:sint;format:hex;#a7 < 1> send packet: + < 18> send packet: $qRegisterInfo8#7a < 1> read packet: + < 58> read packet: $name:t0;bitsize:64;offset:64;encoding:sint;format:hex;#b6 < 1> send packet: + < 18> send packet: $qRegisterInfo9#7b < 1> read packet: + < 58> read packet: $name:t1;bitsize:64;offset:72;encoding:sint;format:hex;#b6 < 1> send packet: + < 18> send packet: $qRegisterInfoa#a3 < 1> read packet: + < 58> read packet: $name:t2;bitsize:64;offset:80;encoding:sint;format:hex;#b6 < 1> send packet: + < 18> send packet: $qRegisterInfob#a4 < 1> read packet: + < 58> read packet: $name:t3;bitsize:64;offset:88;encoding:sint;format:hex;#bf < 1> send packet: + < 18> send packet: $qRegisterInfoc#a5 < 1> read packet: + < 58> read packet: $name:t4;bitsize:64;offset:96;encoding:sint;format:hex;#bf < 1> send packet: + < 18> send packet: $qRegisterInfod#a6 < 1> read packet: + < 59> read packet: $name:t5;bitsize:64;offset:104;encoding:sint;format:hex;#e6 < 1> send packet: + < 18> send
Re: [lldb-dev] gdb-remote protocol questions
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 < > lldb-dev@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 > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > (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 0x 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 volatil
