On Feb 13, 2013, at 7:06 AM, Benjamin Kemper <[email protected]> wrote:
> Everything works! It was the "generic:<reg>" pair that was missing... I > missed it somehow when implementing the "qRegisterInfo" packet response. Great! > I have two last questions (hopefully...): > 1. In our backend we currently place the initial breakpoint at: > * thread #1: tid = 0x0707, 0x00007fff679ae028 dyld`_dyld_start, stop reason = > signal SIGINT > frame #0: 0x00007fff679ae028 dyld`_dyld_start This is where all processes stop when started with posix_spawn with the extra attribute flag that waits for debugger. You might want to switch to SIGSTOP instead of SIGINT to be just like all other MacOSX processes. > Which doesn't seem right on OSX since when I try to continue it stops again > at: > * thread #1: tid = 0x0707, 0x00007fff679ba6e6 > dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info > const*) + 1, stop reason = signal SIGTRAP > frame #0: 0x00007fff679ba6e6 dyld`gdb_image_notifier(dyld_image_mode, > unsigned int, dyld_image_info const*) + 1 LLDB sets a breakpoint here so it can figure out when shared libraries are loaded/unloaded. Since the offset is "+ 1", you are probably having trouble with the following sequence: 1 - run and hit breakpoint 0x00007fff679ba6e5 2 - disable BP at 0x00007fff679ba6e5 3 - single step one thread only to get past the current instruction 4 - re-enable BP at 0x00007fff679ba6e5 5 - continue So keep a close eye on your packet log around this time. Also note we have a packet disassembler in: lldb/scripts/disasm-gdb-remote.pl Just run it on your packet log and you will get more human readable output: ./lldb/scripts/disasm-gdb-remote.pl packet-log.txt > > And on the next continue it crashes. We have encountered something similar on > Windows where it has a "safe" point from which the debugger is allowed to > connect and I'm guessing that this is also the case in OSX. Where does LLDB > inserts it's first breakpoint? Our first breakpoint is the DYLD breakpoint on gdb_image_notifier and the breakpoints the users sets. > > 2. It seems as if LLDB doesn't find the correct PID of the process it > connects to, I always get PID 1799 which doesn't seem right. I didn't see any > packet where this information is communicated in so how does LLDB get the > target process PID? I don't believe we do get this correct right now, and there isn't a packet in the GDB remote protocol that gets this as far as I know. We will probably add a "qProcessInfo" packet that can returns a set of key:value pairs just like the thread stop info packets. Let me know if the above hint helps at all. Feel free to send me a packet dump offline as I am pretty good and looking at the flow of the program from the GDB packet logs and figuring out what is going wrong. Greg > > Thanks again for all the great assistance, > Benjamin. > > > On Tue, Feb 12, 2013 at 7:58 PM, Greg Clayton <[email protected]> wrote: > > On Feb 12, 2013, at 7:19 AM, Benjamin Kemper <[email protected]> wrote: > > > Greg, > > > > First of all thanks for the highly informative answers! > > > > Regarding the 'kill' command that was sent, I have no idea also why it > > happend, but somewhere during the work day (after a few hours of going > > through LLDB code) it stopped happening... > > > > So now LLDB reads all the register values correctly using the `p packets, > > and regarding the expedited registers I believe I already pass them with > > the stop reply, see example: > > <lldb.process.gdb-remote.async> < 78> read packet: > > $T0b06:cce2f16cff7f0000;07:28df8e52ff7f0000;10:0000000000000000;thread:707;#15 > > > > I hoped that once LLDB will get all the registers it will be able to > > construct the stack frame but it fails to do so. I thought maybe I'm > > missing the qShlibInfoAddr so I implemented it also but that didn't help > > also. > > Have you implemented the qHostInfo packet? > > send packet: $qHostInfo#00 > read packet: > $cputype:16777223;cpusubtype:3;ostype:macosx;watchpoint_exceptions_received:after;vendor:apple;endian:little;ptrsize:8;#00 > > Maybe we just don't know the target triple (specified by "ostype", "vendor" > and here the cpu type + subtype) that we are debugging? You can get around > this by specifying a full triple when you make your target: > > (lldb) target create --arch x86_64-apple-macosx <EXE> > > But it is always better to specify it exactly through the qHostInfo if you > can. > > > > > The command I didn't implement yet is "qThreadStopInfo", could this be the > > reason why the stack trace is not constructed or am I missing something > > else? > > No, that wouldn't do it. It could be because you didn't fully specify your > generic registers in the responses to the qRegisterInfo packets. It could be > due to an unknown target triple that made no dynamic loader plug-in be > selected. If you can send me a full transcript of all gdb-remote packets > offline, I will take a look and see what I can figure out. > > > Also, to implement the "qShlibInfoAddr" packet I've used the following > > snippet: > > struct dyld_all_image_infos* getImageInfosFromKernel > > () > > { > > task_dyld_info_data_t task_dyld_info; > > mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT; > > > > > > if > > ( task_info(mach_task_self(), TASK_DYLD_INFO, > > (task_info_t)&task_dyld_info, &count) ) { > > FAIL( > > "all_image_infos: task_info() failed" > > ); > > exit(0); > > } > > > > return (struct > > dyld_all_image_infos*)(uintptr_t)task_dyld_info.all_image_info_addr; > > } > > > > Does it get the required address for the result packet? > > Yes, but you wouldn't want to exit(0) if you failed to get the info right? > Just return an invalid address. > > A few questions for you: what are you trying to debug? What arch? It sounds > like this is for a user space MacOSX program? The triple specified when > creating the target and/or from the qHostInfo will help determine which > shared libraries are loaded and where they are loaded. This will then allow > LLDB to resolve "load" addresses back into "file" relative addresses so we > can backtrace. > > > > Thanks in advance, > > Benjamin. > > > > > > On Mon, Feb 11, 2013 at 8:33 PM, Greg Clayton <[email protected]> wrote: > > > > On Feb 10, 2013, at 6:58 AM, Benjamin Kemper <[email protected]> wrote: > > > > > I noticed something that I've missed when sending the previous Email. > > > Looking at the logs, I see LLDB sending "kill" command for no reason: > > > <lldb.driver.main-thread> < 18> send packet: $m1039ede00,200#86 > > > 1 <lldb.driver.main-thread> < 1> read packet: + > > > 0 <lldb.driver.main-thread> <1028> read packet: > > > $4b4c5752000000000000000000000000c04e0000014e0000004e000000000000000000000000000010de9e030100000014de9e030100000018de9e030100000020 > > > 1 <lldb.driver.main-thread> < 1> send packet: + > > > 2 <lldb.driver.main-thread> < 18> send packet: $m1038d4200,200#21 > > > 3 <lldb.driver.main-thread> < 1> read packet: + > > > 4 <lldb.driver.main-thread> <1028> read packet: > > > $e97bf4ffff6666666666662e0f1f8400000000009090909090909090909090909090909090909090909090909090909090909090909090909090909090909090e9 > > > 5 <lldb.driver.main-thread> < 1> send packet: + > > > 6 <lldb.driver.main-thread> < 21> send packet: $Z0,7fff5fc0d6e5,1#de > > > 7 <lldb.driver.main-thread> < 1> read packet: + > > > 8 <lldb.driver.main-thread> < 6> read packet: $OK#9a > > > 9 <lldb.driver.main-thread> < 1> send packet: + > > > 10 <lldb.driver.main-thread> < 16> send packet: $qfThreadInfo#bb > > > 11 <lldb.driver.main-thread> < 1> read packet: + > > > 12 <lldb.driver.main-thread> < 8> read packet: $m707#0b > > > 13 <lldb.driver.main-thread> < 1> send packet: + > > > 14 <lldb.driver.main-thread> < 16> send packet: $qsThreadInfo#c8 > > > 15 <lldb.driver.main-thread> < 1> read packet: + > > > 16 <lldb.driver.main-thread> < 5> read packet: $l#6c > > > 17 <lldb.driver.main-thread> < 1> send packet: + > > > 18 <lldb.driver.main-thread> < 18> send packet: $z0,1005f00d7,1#5a > > > 19 <lldb.driver.main-thread> < 1> read packet: + > > > 20 <lldb.driver.main-thread> < 6> read packet: $OK#9a > > > 21 <lldb.driver.main-thread> < 1> send packet: + > > > 22 <lldb.driver.main-thread> < 21> send packet: $z0,7fff5fc0d6e5,1#fe > > > 23 <lldb.driver.main-thread> < 1> read packet: + > > > 24 <lldb.driver.main-thread> < 6> read packet: $OK#9a > > > 25 <lldb.driver.main-thread> < 1> send packet: + > > > 26 <lldb.driver.main-thread> < 5> send packet: $k#6b > > > 27 <lldb.driver.main-thread> < 1> read packet: + > > > 28 <lldb.driver.main-thread> < 6> read packet: $OK#9a > > > 29 <lldb.driver.main-thread> < 1> send packet: + > > > 30 6> send packet: $p2#a2 > > > 31 <lldb.driver.main-thread> < 1> read packet: + > > > 32 <lldb.driver.main-thread> < 4> read packet: $#00 > > > 33 <lldb.driver.main-thread> < 1> send packet: + > > > 34 <lldb.driver.main-thread> < 6> send packet: $p3#a3 > > > > > > Here are my commands in the lldb console: > > > ➜ build lldb /bin/ls > > > Current executable set to '/bin/ls' (x86_64). > > > (lldb) log enable -f /tmp/packets.txt gdb-remote packets > > > (lldb) process connect -p gdb-remote connect://localhost:58985 > > > Process 1799 stopped > > > * thread #1: tid = 0x0707, , stop reason = signal SIGINT > > > frame #0: > > > (lldb) > > > > > > Why might LLDB send the 'kill' command without "permission"? > > > > You will need to debug the LLDB sources to see why this isn't being sent. I > > know of no reason why this should be happening, so this is probably a bug. > > > > > > > > The weird thing is that after it sends the kill command, it then start > > > requesting for register values using the '$p' commands... > > > > > > Any ideas why this is happening? > > > > > > > No, none at all. You will need to debug this. The only place the "k" packet > > is sent is from inside: > > > > ProcessGDBRemote::DoDestroy () > > > > There is logging that can be enabled. Add the "process" category to the > > "gdb-remote" logging and use the "--stack" option to print out a backtrace: > > > > (lldb) log enable --stack -f /tmp/process.txt gdb-remote process > > > > You should then see a stack backtrace to see who is calling DoDestroy()... > > > > > > > > > > > On Sun, Feb 10, 2013 at 3:19 PM, Benjamin Kemper <[email protected]> > > > wrote: > > > Hi, > > > > > > I'm implementing a debugger backend that implements the gdb remote > > > protocol and adding extensions to support LLDB also. > > > > > > I've added support for the qRegisterInfo packet and I've noticed in the > > > logs that LLDB uses the p/P packets instead of the G/g packets. > > > > > > Is there a special reason why it uses multiple packets instead of one? > > > > > > Maybe I didn't implement enough "information" packets and LLDB doesn't > > > know how to read g/G packets? If so, what packets are missing? > > > > > > Thanks, > > > Benjamin. > > > > > > _______________________________________________ > > > lldb-dev mailing list > > > [email protected] > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
