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

[Todd Fiala]

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 <gclayton at 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 <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
> >
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140825/00553e8a/attachment.html>