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)
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.
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.
We probably should add some new packets to discover then via GDB remote packets kind of like the qRegisterInfo packets...
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 a related note, we might want to think about the following:
- Windows will eventually need something to handle the gdb-remote stop notification signal numbers. Maybe UnixSignals isn’t the best name for this concept.
- Having the MacOSX signals as the base class UnixSignals, while having derived LinuxSignals and FreeBSDSignals for those platforms, is perhaps a bit misleading. (This probably evolved since the UnixSignals class handles all the data management and the derived classes are really class-based factories — maybe we are abstracting the wrong thing by deriving, and maybe just need to work directly with a UnixSignals struct, better handling the construction).
Just some thoughts. This will eventually need to be dealt with if we do llgs over to Windows. (If not, maybe we can postpone this for a while).