jingham added a comment.
I'm a little confused by the analysis so far. SBTarget.Launch calls
Target::Launch. That sets up a hijacker for the "stop at the first
instruction" event regardless of the Sync mode. Once that succeeds, if the
Debugger is set for Synchronous execution Target::Launch does:
if (synchronous_execution) {
// Now we have handled the stop-from-attach, and we are just
// switching to a synchronous resume. So we should switch to the
// SyncResume hijacker.
m_process_sp->RestoreProcessEvents();
m_process_sp->ResumeSynchronous(stream);
and ResumeSynchronous sets up a Hijacker to wait for and consume the stop event
for the first "user stop" after the launch:
ListenerSP listener_sp(
Listener::MakeListener(g_resume_sync_name));
HijackProcessEvents(listener_sp);
Status error = PrivateResume();
if (error.Success()) {
StateType state = WaitForProcessToStop(llvm::None, nullptr, true,
listener_sp, stream);
This is the same routine used by all the "target running" commands in sync mode.
So I don't see how your event listening thread could have heard about the
second stop event as the events should not have been sent to it.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D119548/new/
https://reviews.llvm.org/D119548
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
