That's the stop at entry stop. The code you quoted is in a block that starts
with:
if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false)
{
So we've stopped at the entry point, but the user didn't want to know about
that, so we resume and wait for a "real" stop.
Jim
> On Mar 20, 2015, at 4:30 PM, Zachary Turner <[email protected]> wrote:
>
> I'm a little confused. You said that in synchronous execution, Launch won't
> return until the process has stopped. That makes sense, but it already
> checks that the process has stopped once regardless of whether synchronous
> execution is set. Then, it calls PrivateResume() (even if
> synchronous_execution is set), and then waits for the process to stop again?
> What would trigger this second stop? Target::Launch already asked it to
> resume, so now it's happily running while Target::Launch is waiting for it to
> stop a second time.
>
> On Fri, Mar 20, 2015 at 4:23 PM <[email protected]> wrote:
> In synchronous execution, the "Launch" command won't return till the process
> has stopped. The point of synchronous execution is that you can do:
>
> break set -n foo
> run
> bt
>
> So "run" can't return till the breakpoint has been hit. That is why it waits
> for the process to stop. I'm not quite sure why this is done in
> Target::Launch, in other cases (e.g. in for "step" and "continue" the command
> object is the one that takes care of waiting for the stop. Launch is a
> little funny however, because it can't use the normal process wait mechanism
> to do its job since the real process isn't alive when it has to start
> waiting...
>
> I think the reason you are hanging here is that the code that reads in all
> the init statements runs an event loop temporarily while it is reading them
> in, and the kills that and hands off the the real command execution loop, and
> this continuation gets lost in the handoff. I thought Greg had already fixed
> that, but maybe it's still sitting in his queue.
>
> Jim
>
>
>
>
> > On Mar 20, 2015, at 3:57 PM, Zachary Turner <[email protected]> wrote:
> >
> > I ran into an issue earlier where I tried to make a .lldbinit file with
> > some lines like this:
> >
> > file a.out
> > run
> >
> >
> > When this happens the process runs, the breakpoint gets hit and I see the
> > source listing, it returns to the lldb prompt, but then I can't type
> > anything. It appears LLDB is deadlocked inside of Target::Launch() at the
> > following location:
> >
> > if (!synchronous_execution)
> > m_process_sp->RestoreProcessEvents ();
> >
> > error = m_process_sp->PrivateResume();
> >
> > if (error.Success())
> > {
> > // there is a race condition where this thread will
> > return up the call stack to the main command
> > // handler and show an (lldb) prompt before
> > HandlePrivateEvent (from PrivateStateThread) has
> > // a chance to call PushProcessIOHandler()
> > m_process_sp->SyncIOHandler(2000);
> >
> > if (synchronous_execution)
> > {
> >
> > state = m_process_sp->WaitForProcessToStop (NULL, NULL, true,
> > hijack_listener_sp.get(), stream);
> > const bool must_be_alive = false; // eStateExited
> > is ok, so this must be false
> > if (!StateIsStoppedState(state, must_be_alive))
> > {
> > error.SetErrorStringWithFormat("process isn't
> > stopped: %s", StateAsCString(state));
> > }
> > }
> > }
> >
> > Normally when I'm using LLDB and entering the commands myself, this
> > synchronous_execution value is not set, and everything works as expected.
> > How is this supposed to work? What does my plugin need to do differently
> > in order to handle this case? The process has already stopped once and
> > resumed, so I'm not sure why it would need to stop again? I see that it's
> > not restoring process events in the case of synchronous execution, so maybe
> > it should have never resumed in the first place?
> > _______________________________________________
> > 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
