From 5bd5fa63bf6caf90170f9e703e0dba433fe407a7 Mon Sep 17 00:00:00 2001
From: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Date: Wed, 11 Nov 2009 11:34:16 +0100
Subject: [PATCH] be more lenient when matching the stops at _start
archer reports stops at tbreaks properly, so checking for an empty stop
reason is no particularly good idea. instead, we simply skip *all* stops
at the entry point, assuming the user will not really set a breakpoint
there anyway.
Reviewed-by: hjk
---
src/plugins/debugger/gdb/gdbengine.cpp | 29 ++++++++++++--------------
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/src/plugins/debugger/gdb/gdbengine.cpp b/src/plugins/debugger/gdb/gdbengine.cpp
index 4878ef6e7e6..2fec141eeb3 100644
--- a/src/plugins/debugger/gdb/gdbengine.cpp
+++ b/src/plugins/debugger/gdb/gdbengine.cpp
@@ -1184,23 +1184,20 @@ void GdbEngine::handleStopResponse(const GdbMi &data)
if (!m_entryPoint.isEmpty()) {
GdbMi frameData = data.findChild("frame");
if (frameData.findChild("addr").data() == m_entryPoint) {
- if (reason == "signal-received"
- && data.findChild("signal-name").data() == "SIGSTOP") {
- // For some reason, attaching to a stopped process causes *two* stops
- // when trying to continue (kernel i386 2.6.24-23-ubuntu, gdb 6.8).
- // Interestingly enough, on MacOSX no signal is delivered at all.
- continueInferiorInternal();
- return;
- }
- if (reason.isEmpty()) { // tbreak does that
- // For programs without -pthread under gdb <= 6.8.
- if (!inferiorPid())
- postCommand(_("info proc"), CB(handleInfoProc));
- continueInferiorInternal();
- return;
- }
+ // 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 stops. No need to waste time on further checks.
+ // We are past the initial stop(s). No need to waste time on further checks.
m_entryPoint.clear();
}
#endif
--
GitLab