forked from OSchip/llvm-project
[lldb] [Process/FreeBSDRemote] Fix attaching via lldb-server
Fix two bugs that caused attaching to a process in a pre-connected lldb-server to fail. These are: 1. Prematurely reporting status in NativeProcessFreeBSD::Attach(). The SetState() call defaulted to notify the process, and LLGS tried to send the stopped packet before the process instance was assigned to it. While at it, add an assert for that in LLGS. 2. Duplicate call to ReinitializeThreads() (via SetupTrace()) that overwrote the stopped status in threads. Now SetupTrace() is called directly by NativeProcessFreeBSD::Attach() (not the Factory) in place of ReinitializeThreads(). This fixes at least commands/process/attach/TestProcessAttach.py and python_api/hello_world/TestHelloWorld.py. Differential Revision: https://reviews.llvm.org/D90525
This commit is contained in:
parent
f893b29397
commit
8e6bcbb417
|
@ -698,8 +698,9 @@ Status NativeProcessFreeBSD::Attach() {
|
|||
0)
|
||||
return Status(errno, eErrorTypePOSIX);
|
||||
|
||||
/* Initialize threads */
|
||||
status = ReinitializeThreads();
|
||||
// Initialize threads and tracing status
|
||||
// NB: this needs to be called before we set thread state
|
||||
status = SetupTrace();
|
||||
if (status.Fail())
|
||||
return status;
|
||||
|
||||
|
@ -707,7 +708,8 @@ Status NativeProcessFreeBSD::Attach() {
|
|||
static_cast<NativeThreadFreeBSD &>(*thread).SetStoppedBySignal(SIGSTOP);
|
||||
|
||||
// Let our process instance know the thread has stopped.
|
||||
SetState(StateType::eStateStopped);
|
||||
SetCurrentThreadID(m_threads.front()->GetID());
|
||||
SetState(StateType::eStateStopped, false);
|
||||
return Status();
|
||||
}
|
||||
|
||||
|
|
|
@ -1728,6 +1728,7 @@ GDBRemoteCommunicationServerLLGS::SendStopReasonForState(
|
|||
case eStateSuspended:
|
||||
case eStateStopped:
|
||||
case eStateCrashed: {
|
||||
assert(m_debugged_process_up != nullptr);
|
||||
lldb::tid_t tid = m_debugged_process_up->GetCurrentThreadID();
|
||||
// Make sure we set the current thread so g and p packets return the data
|
||||
// the gdb will expect.
|
||||
|
|
Loading…
Reference in New Issue