[lldb-dev] process launch: exec past eLaunchFlagDebug for debugserver local debugging

[Greg Clayton]

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 <tfiala at 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 <tfiala at google.com> wrote:
> 
> 
> 
> On Fri, Aug 22, 2014 at 2:59 PM, Todd Fiala <tfiala at 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 at 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 |	 tfiala at google.com |	 650-943-3180
> 
> 
> 
> 
> -- 
> Todd Fiala |	 Software Engineer |	 tfiala at google.com |	 650-943-3180
> 
> 
> 
> 
> -- 
> Todd Fiala |	 Software Engineer |	 tfiala at google.com |	 650-943-3180
>