Can't set watchpoints on launching threads on Linux LLGS.

[chaoren]

Summary

They'll be set anyway when the thread starts running, so the launching threads
should just ignore the set request.

[chaoren]

It seems like the only state in which it's possible to set a hardware watchpoint is eStateStopped. All other states either can't be examined by ptrace or has already crashed. Am I understanding this correctly? Right now I'm running into a problem where watchpoint is being set while the state is eStateRunning. That's a probably caused by an unrelated problem of threads failing to be stopped.

[ovyalov]

In D7914#135266, @chaoren wrote:

It seems like the only state in which it's possible to set a hardware watchpoint is eStateStopped. All other states either can't be examined by ptrace or has already crashed. Am I understanding this correctly? Right now I'm running into a problem where watchpoint is being set while the state is eStateRunning. That's a probably caused by an unrelated problem of threads failing to be stopped.

Yes, it's safe to send PTRACE request to a thread when it in stopped state. How do you reproduce this situation with setting watchpoint on a running thread?

[chaoren]

Yes, it's safe to send PTRACE request to a thread when it in stopped

state.

But is it *only* the stopped state? It shouldn't be possible to set a
watchpoint in any other state right?

How do you reproduce this situation with setting watchpoint on a running

thread?

TestSetWatchlocation and TestTargetWatchAddress both occasionally fail due
to this. It manifests as failing to set watchpoint. The threads should have
been stopped, but they're still eStateRunning when the process tried to set
watchpoints.

[ovyalov]

In D7914#135273, @chaoren wrote:

Yes, it's safe to send PTRACE request to a thread when it in stopped

state.

But is it *only* the stopped state? It shouldn't be possible to set a
watchpoint in any other state right?

Yes - I think so.

How do you reproduce this situation with setting watchpoint on a running

thread?

TestSetWatchlocation and TestTargetWatchAddress both occasionally fail due
to this. It manifests as failing to set watchpoint. The threads should have
been stopped, but they're still eStateRunning when the process tried to set
watchpoints.

It will be interesting to see gdb-remote logs for these tests - to check whether llgs got vCont continue request first and then received Z request for watchpoint.. Or maybe lldb thinks that all threads are stopped in inferior but llgs is messing with some threads' states.

source/Plugins/Process/Linux/NativeThreadLinux.cpp

#endif
     return m_reg_context_sp;
 }
 
 Error
 NativeThreadLinux::SetWatchpoint (lldb::addr_t addr, size_t size, uint32_t watch_flags, bool hardware)
 {
     if (!hardware)
         return Error ("not implemented");
+    if (m_state == eStateLaunching)
+        return Error ();
     Error error = RemoveWatchpoint(addr);
     if (error.Fail()) return error;
     NativeRegisterContextSP reg_ctx = GetRegisterContext ();
     uint32_t wp_index =
         reg_ctx->SetHardwareWatchpoint (addr, size, watch_flags);
     if (wp_index == LLDB_INVALID_INDEX32)
         return Error ("Setting hardware watchpoint failed.");
     m_watchpoint_index_map.insert({addr, wp_index});