Yeah, we could consider doing that. I've actually got a change in my public dev-llgs-local branch that adds a UnixSignalsSP as a constructor arg to Process, defaulting to a new Host::GetUnixSignals() if not specified. It's here:
https://github.com/tfiala/lldb/commit/f85a1b1bad570fe9a9703118c6522d28eea3e202 I'm going to rework it a bit to use HostInfo rather than Host before I upstream that part. I was handling it right for a true llgs remote setup (like via (lldb) gdb-remote {host}:{port}), but when doing llgs local where we emulate local MacOSX debugging, it was getting the default UnixSignals, which are only good for MacOSX. On Mon, Aug 25, 2014 at 10:56 AM, Greg Clayton <gclay...@apple.com> wrote: > 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 > > > > -- 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
