Heh okay so Jim's comment on PTRACE_TRACEME is perfect, then. Somehow I missed that option - I've been doing PTRACE_ATTACH from the parent side. I was thinking I had to attach on lldb, detach (but stopped), then have llgs attach.
But really all I needed was "child PTRACE_TRACEME" and wait for the (one and only) ptracer --- llgs --- to pick it up. (And as Greg pointed out, need to skip that first exec). That *will* be easier and will be able to follow the flow. Thanks, all! -Todd On Thu, Jul 24, 2014 at 2:22 PM, Greg Clayton <[email protected]> wrote: > We moved away from launching debugserver with args to setup and launch the > process we can properly setup all things (environment, disable ASLR, set > arch, set stdin/out/err files, set working dir, much more) and then launch. > It also allows the host layer to do all the launching instead of sending > hundreds of slow packets to set all this up. > > > > On Jul 24, 2014, at 2:12 PM, [email protected] wrote: > > > > When you connect to debugserver from lldb, and it doesn't have a process > running, you can already just tell it to "run" and it will start up the > target process. That was actually the default in lldb for quite some time. > I don't remember now why we switched to having lldb launch things and then > attach debugserver to them, do you Greg? > > > > Jim > > > >> On Jul 24, 2014, at 2:00 PM, Todd Fiala <[email protected]> wrote: > >> > >> Ah I see. Yeah that would work around the issues we have on Linux where > different kernel versions differ on the handling of detaching from ptrace > during a group stop (which is where I was originally going to start - have > lldb fork/exec/ptrace, then detach, leaving process stopped, and hand off > to llgs). > >> > >> So in that case: > >> > >> lldb can do the fork/exec, pass the inferior pid to llgs, wait for that > to attach, lldb does the write to the pipe and close after this point, and > then everything can move along merrily. > >> > >> All that said, this does sound way more complicated than just modifying > the flow to have llgs just launch the exe in the first place like it > already can. > >> > >> Greg - is there any reason it would be trouble for you guys if we > modified the local debugging flow to have debugserver/llgs launch the > inferior? Then this would just work in both places without having to jump > through implementing the stop-on-launch bits on Linux and anywhere else > that didn't have that startup mode? > >> > >> -Todd > >> > >> > >> On Thu, Jul 24, 2014 at 1:40 PM, Greg Clayton <[email protected]> > wrote: > >> Richard is suggesting you: > >> > >> - open a pipe > >> - fork() > >> - child: close the write file descriptor and read from the read end > (which blocks waiting for the parent) > >> - parent: close the read file descriptor > >> - parent: ptrace(PT_ATTACH, child_pid, ...) > >> - parent: write a byte to write end of the pipe and close write end > >> - child: read a byte from the read end and close the read end of pipe > >> > >> > >>> On Jul 24, 2014, at 1:28 PM, Todd Fiala <[email protected]> wrote: > >>> > >>> Hi Richard, > >>> > >>> Can you say more about this part: > >>>> is to simply use a pipe between the parent and child to indicate when > they're both ready. > >>> > >>> I think I assumed too much context with Greg - > >>> > >>> The exact scenario we're talking about is: > >>> > >>> 1. Start up a process, going to be debugged, needs to be stopped at > very-very start point (i.e. c/c++ library entry point). Debugger will pick > it up from here. > >>> > >>> 2. Apple's flow for this when debugging over debugserver on a local > process is to start the exe up from lldb, in a mode that starts the process > but keeps it in (essentially) a group-stop state at that first entry point. > Then they have debugserver attach to that process. > >>> > >>> I could try to rewire that scenario for Linux/* (which I had > originally considered and may eventually get back to that point) to have > llgs configured and then have llgs launch the process, which would work > right now. However, at the moment I'd like to see if I can not monkey > around too much with the flow of starting a local llgs-debugged exe and > just follow MacOSX's flow here. > >>> > >>> Does your idea still fit into that context? > >>> > >>> -Todd > >>> > >>> > >>> > >>> On Thu, Jul 24, 2014 at 12:46 PM, Richard Mitton < > [email protected]> wrote: > >>> A better way, rather than messing with signals, is to simply use a > pipe between the parent and child to indicate when they're both ready. > >>> > >>> Richard Mitton > >>> [email protected] > >>> > >>> > >>> On 07/24/2014 11:28 AM, Greg Clayton wrote: > >>> On Jul 23, 2014, at 4:44 PM, Todd R. Fiala <[email protected]> > wrote: > >>> > >>> Hey Greg, > >>> > >>> I’m looking into implementing process start-up so I can just follow > your flow of launching the exe, then connecting via llgs with reverse > connect. I’d like to take a shot at getting Linux processes to start up in > a “stopped at initial entry point” behavior rather than doing something > different than MacOSX at this point. > >>> > >>> Linux PTRACE doesn’t provide this out of the box. There is an > alternative that could work but is not reliable across Linux kernel > versions: detaching from a PTRACE’d exe during a group-stop will leave it > stopped. I think the initial startup signal I get with PTRACE may yield a > group stop. If it’s not, I can immediately turn around and issue a stop, > deliver that and get the real group stop. (Not 100% sure I could do that > last part with guaranteed no-execution semantics at the entry point > location). Unfortunately, the detach is not reliable everywhere I need > this to run to keep the process in a stopped state at that point for > handoff to llgs. > >>> What I could do instead, is fork, and have the child process self-send > a SIGSTOP before doing the exec. And, on Linux (and maybe FreeBSD), when > llgs attaches, it just needs to know that it has to wait for one exec > signal before the process really starts. (I’m not sure if there is a shell > mode for debugging with Linux - if there is, then we need to exec through > the shell script too, I think — I don’t remember seeing that on the linux > code path so it likely is buggy and/or unsupported at the moment). In any > event, if I do this, I’m pretty sure I can guarantee that I can start a > process in debug-ready mode with the caveat that there is an exec that has > to be silently ignored when llgs attaches. > >>> > >>> How does that sound? Thoughts? > >>> The idea sounds good, as you can just do: > >>> > >>> kill(getpid(), SIGSTOP) > >>> > >>> but you can run into problems with the foreground app in a terminal > not being able to SIGSTOP itself and you might get some SIGTTOU or SIGTTIN > signals. > >>> > >>> But do try it out. The ProcessLaunchInfo have: > >>> > >>> uint32_t > >>> GetResumeCount () const > >>> { > >>> return m_resume_count; > >>> } > >>> > >>> void > >>> SetResumeCount (uint32_t c) > >>> { > >>> m_resume_count = c; > >>> } > >>> > >>> > >>> So you just need to set this to 1 and it will continue past 1 exec > without trying to read the dyld info for any execs before m_resume_count > gets to zero. > >>> > >>> Greg > >>> > >>> > >>> _______________________________________________ > >>> lldb-dev mailing list > >>> [email protected] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >>> > >>> > >>> _______________________________________________ > >>> lldb-dev mailing list > >>> [email protected] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >>> > >>> > >>> > >>> -- > >>> Todd Fiala | Software Engineer | [email protected] | > 650-943-3180 > >>> > >>> _______________________________________________ > >>> lldb-dev mailing list > >>> [email protected] > >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >> > >> > >> > >> > >> -- > >> Todd Fiala | Software Engineer | [email protected] | > 650-943-3180 > >> > >> _______________________________________________ > >> lldb-dev mailing list > >> [email protected] > >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > -- -Todd
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
