jingham added a comment. In D119548#3321397 <https://reviews.llvm.org/D119548#3321397>, @ilya-nozhkin wrote:
> In D119548#3321357 <https://reviews.llvm.org/D119548#3321357>, @jingham wrote: > >> SBTarget.Launch calls Target::Launch. That sets up a hijacker for the "stop >> at the first instruction" event regardless of the Sync mode. > > The problem that it sets up this hijacker too late. See this part of the log > (lines starting with // are my comments): > > // The process has been launched successfully, its internal hijacker is > removed. > 0x000002875FCB1AE0 Broadcaster("lldb.process")::RestoreBroadcaster (about > to pop listener("LaunchEventHijack")=0x000002875FFCF890) > Process::SetPublicState (state = stopped, restarted = 0) > Process::SetPublicState (stopped) -- unlocking run lock > Process::lldb_private::Process::StartPrivateStateThread() starting private > state thread > > // Some internal magic happens inside the private state thread. > Process::lldb_private::Process::ControlPrivateStateThread (signal = 4) > Sending control event of type: 4. > 0000028760372F90 > Broadcaster("lldb.process.internal_state_control_broadcaster")::BroadcastEvent > (event_sp = {0000028760571460 Event: broadcaster = 000002876047C4C0 > (lldb.process.internal_state_control_broadcaster), type = 0x00000004 > (control-resume), data = {Generic Event Data}}, unique =0) hijack = > 0000000000000000 > 000002875FFD00D0 > Listener('lldb.process.internal_state_listener')::AddEvent (event_sp = > {0000028760571460}) > Process::lldb_private::Process::RunPrivateStateThread (arg = > 000002876047C350, pid = 9944) thread starting... > timeout = <infinite>, event_sp)... > this = 0x000002875FFD00D0, timeout = <infinite> for > lldb.process.internal_state_listener > 000002875FFD00D0 'lldb.process.internal_state_listener' > Listener::FindNextEventInternal(broadcaster=000002876047C4C0, > broadcaster_names=0000000000000000[0], event_type_mask=0x00000000, remove=1) > event 0000028760571460 > Process::lldb_private::Process::RunPrivateStateThread (arg = > 000002876047C350, pid = 9944) got a control event: 4 > 000002875FFCF5D0 Listener::StartListeningForEvents (broadcaster = > 000002876047C9C8, mask = 0x00000020) acquired_mask = 0x00000020 for > Communication::SyncronizeWithReadThread > timeout = <infinite>, event_sp)... > this = 0x000002875FFD00D0, timeout = <infinite> for > lldb.process.internal_state_listener > Process::ShouldBroadcastEvent (00000287604D4CB0) => new state: stopped, > last broadcast state: stopped - YES > Process::lldb_private::Process::HandlePrivateEvent (pid = 9944) > broadcasting new state stopped (old state stopped) to public > > // Process broadcasts the stop event. > 000002875FCB1AE0 Broadcaster("lldb.process")::BroadcastEvent (event_sp = > {00000287604D4CB0 Event: broadcaster = 000002876047C378 (lldb.process), type > = 0x00000001 (state-changed), data = { process = 000002876047C350 (pid = > 9944), state = stopped}}, unique =0) hijack = 0000000000000000 > > // It is catched by "lldb.Debugger"! > 000002875DB0BD40 Listener('lldb.Debugger')::AddEvent (event_sp = > {00000287604D4CB0}) > > // And only now the target adds its hijacking listener! > 0x000002875FCB1AE0 Broadcaster("lldb.process")::HijackBroadcaster > (listener("lldb.Target.Launch.hijack")=0x000002875FFCFE10) That can't be it. Target::Launch consumes the "stop at entry" event when it calls WaitForProcessToStop. And then we set the Resume hijacker before we resume the process, so there weren't any other stop events around at that point. It's also odd that we choose to broadcast a stop event when the state is stopped. We don't usually broadcast duplicate events. Somewhere we must be being helpful and sending out a priming event when the private state thread gets resumed. But I couldn't find where we were doing that on a quick pass. 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