Commit 0d3ca6da authored by hjk's avatar hjk
Browse files

debugger: make attach to running process stop the process (again)

parent 7812c958
......@@ -78,10 +78,11 @@ void AttachGdbAdapter::setupInferior()
void AttachGdbAdapter::runEngine()
{
QTC_ASSERT(state() == EngineRunRequested, qDebug() << state());
m_engine->notifyEngineRunAndInferiorStopOk();
m_engine->continueInferiorInternal();
m_engine->showStatusMessage(tr("Attached to process %1.")
.arg(m_engine->inferiorPid()));
m_engine->notifyEngineRunAndInferiorStopOk();
GdbMi data;
m_engine->handleStop0(data);
}
void AttachGdbAdapter::handleAttach(const GdbResponse &response)
......
......@@ -1215,6 +1215,34 @@ void GdbEngine::handleStopResponse(const GdbMi &data)
notifyInferiorStopOk();
}
// FIXME: Replace the #ifdef by the "target" architecture.
// FIXME: Is this needed at all anymore?
#ifdef Q_OS_LINUX
if (!m_entryPoint.isEmpty()) {
if (frame.findChild("addr").data() == m_entryPoint) {
// There are two expected reasons for getting here:
// 1) For some reason, attaching to a stopped process causes *two* SIGSTOPs
// when trying to continue (kernel i386 2.6.24-23-ubuntu, gdb 6.8).
// Interestingly enough, on MacOSX no signal is delivered at all.
// 2) The explicit tbreak at the entry point we set to query the PID.
// Gdb <= 6.8 reports a frame but no reason, 6.8.50+ reports everything.
// The case of the user really setting a breakpoint at _start is simply
// unsupported.
if (!inferiorPid()) // For programs without -pthread under gdb <= 6.8.
postCommand("info proc", CB(handleInfoProc));
continueInferiorInternal();
return;
}
// We are past the initial stop(s). No need to waste time on further checks.
m_entryPoint.clear();
}
#endif
handleStop0(data);
}
void GdbEngine::handleStop0(const GdbMi &data)
{
#if 0 // See http://vladimir_prus.blogspot.com/2007/12/debugger-stories-pending-breakpoints.html
// Due to LD_PRELOADing the dumpers, these events can occur even before
// reaching the entry point. So handle it before the entry point hacks below.
......@@ -1244,27 +1272,8 @@ void GdbEngine::handleStopResponse(const GdbMi &data)
}
#endif
// FIXME: Replace the #ifdef by the "target" architecture
#ifdef Q_OS_LINUX
if (!m_entryPoint.isEmpty()) {
if (frame.findChild("addr").data() == m_entryPoint) {
// There are two expected reasons for getting here:
// 1) For some reason, attaching to a stopped process causes *two* SIGSTOPs
// when trying to continue (kernel i386 2.6.24-23-ubuntu, gdb 6.8).
// Interestingly enough, on MacOSX no signal is delivered at all.
// 2) The explicit tbreak at the entry point we set to query the PID.
// Gdb <= 6.8 reports a frame but no reason, 6.8.50+ reports everything.
// The case of the user really setting a breakpoint at _start is simply
// unsupported.
if (!inferiorPid()) // For programs without -pthread under gdb <= 6.8.
postCommand("info proc", CB(handleInfoProc));
continueInferiorInternal();
return;
}
// We are past the initial stop(s). No need to waste time on further checks.
m_entryPoint.clear();
}
#endif
const GdbMi frame = data.findChild("frame");
const QByteArray reason = data.findChild("reason").data();
// This was seen on XP after removing a breakpoint while running
// >945*stopped,reason="signal-received",signal-name="SIGTRAP",
......
......@@ -278,6 +278,7 @@ private: ////////// Gdb Output, State & Capability Handling //////////
void handleResponse(const QByteArray &buff);
void handleStopResponse(const GdbMi &data);
void handleResultRecord(GdbResponse *response);
void handleStop0(const GdbMi &data);
void handleStop1(const GdbResponse &response);
void handleStop1(const GdbMi &data);
StackFrame parseStackFrame(const GdbMi &mi, int level);
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment