> On Nov 11, 2014, at 9:46 AM, Zachary Turner <ztur...@google.com> wrote:
> 
> A follow up question.  Trying to make sure I get this right for the sequence 
> of launching a process.  You launch the process, wait for the initial stop, 
> then lldb resumes your process, then it's running.  Conceptually it seems 
> like the following state sequence makes the most sense
> 
> Upon returning from Process::DoLaunch()   Public = Private = Launching
> After the initial stop is received   Public = launching, private = stopped
> After LLDB calls DoResume()   Public = private = running
> 
> On the other hand, you said I should never touch the public state myself.  
> Did I understand this correctly, or is it ok to set the public state from 
> within my process plugin?

Launching and attaching are funny in that we hijack the public events so they 
don't get delivered to the user. So in the launch and attach case you might 
need to set the public state directly. I would follow what the other plugins 
are doing. Once your process is launched and stopped, you won't ever play with 
the public state directly, but you might need to during launch and attach 
because the events are hijacked. When we hijack the public events, we can 
consume one or more events so they don't get delivered. For example, we have 
sync and async mode. In sync mode when you launch it expects you to wait until 
the process stops before returning from any commands that run the target. So 
your launch could actually consume all events and the process can exit. When 
you return from launch in sync mode, you can then just check the state of the 
process and see if you are stopped or exited. In async mode, we might get the 
first stop of the process (at the entry point with no code having!
  been run), but continue your process for you if you didn't specify to stop at 
entry in your launch prefs. So we actually eat a public stop for the stop at 
the entry, and then resume the process but we don't consume that event...



_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to