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

[Todd Fiala]

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).


On Mon, Aug 25, 2014 at 12:45 PM, Todd Fiala <tfiala at google.com> wrote:

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



-- 
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/30cb6dc1/attachment.html>