We probably should add some new packets to discover then via GDB remote packets kind of like the qRegisterInfo packets...
> On Aug 22, 2014, at 4:04 PM, Todd Fiala <tfi...@google.com> wrote: > > Ok looks like I'm not getting ProcessGDBRemote's concept of UnixSignals > correct for Linux on the lldb-launch, llgs-attach mode for local debugging. > This is causing mismatches in signal numbers --- LinuxSignals differ in some > important ways from the default UnixSignals. > > > On Fri, Aug 22, 2014 at 3:13 PM, Todd Fiala <tfi...@google.com> wrote: > > > > On Fri, Aug 22, 2014 at 2:59 PM, Todd Fiala <tfi...@google.com> wrote: > Hey Greg, > > Where is the code in lldb that does the final 'resume' when we get the > inferior stopped at the entry point with eLaunchFlagDebug? > > I've got my local Linux debugging working with llgs with a band-aid fix to > address the race condition, but I do consistently stop at the entry point to > the program (the exec stop for the final exec into the true inferior process). > > Another symptom I'm seeing (maybe it is related) is that lldb doesn't seem to > know what the target is. IOW, I see this kind of behavior: > > tfiala@tfiala2:/mnt/ssd/work/macosx.sync/mp-git/build-debug$ bin/lldb -- > ~/play/loops/loops > (lldb) target create "/usr/local/google/home/tfiala/play/loops/loops" > Current executable set to '/usr/local/google/home/tfiala/play/loops/loops' > (x86_64). > (lldb) run > Process 20363 launched: '/usr/local/google/home/tfiala/play/loops/loops' > (x86_64) > Process 20363 stopped > * thread #1: tid = 20363, 0x00007f9b806f02d0, name = 'loops', stop reason = > exec > frame #0: 0x00007f9b806f02d0 > -> 0x7f9b806f02d0: movq %rsp, %rdi > 0x7f9b806f02d3: callq 0x7f9b806f3a70 > 0x7f9b806f02d8: movq %rax, %r12 > 0x7f9b806f02db: movl 0x221b17(%rip), %eax > > // ^= here you see the behavior where I stop at the final exec (as I'd expect > at the private level, but I'd expect lldb to want to continue it at the > public level). > > (lldb) c > Process 20363 resuming > i = 0 > i = 1 > i = 2 > i = 3 > i = 4 > i = 5 > i = 6 > i = 7 > i = 8 > i = 9 > Process 20363 exited with status = 0 (0x00000000) > (lldb) run > error: no file in target, create a debug target using the 'target create' > command > > // ^= Huh? I should be able to re-run :-) > > (lldb) > > On this part, I think I may not be clearing out everything that needs to be > cleared out on an exec. I'm going to trace what debugserver/lldb does on > MacOSX when an exec is detected to see if I'm missing anything on the Linux > llgs/lldb side. > > > -- > Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 > > > > > -- > Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 > > > > > -- > Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
