feedc0de/qt-creator
1
0
Fork 0
forked from qt-creator/qt-creator
Code Pull Requests Activity

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

Browse Source
This commit is contained in:
hjk
2010-11-23 12:31:47 +01:00
parent 7812c958fa
commit 0d3ca6da16
3 changed files with 34 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
src/plugins/debugger/gdb/gdbengine.cpp
View File

@@ -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",