forked from qt-creator/qt-creator
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
This commit is contained in:
@@ -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
|
||||
// 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.
|
||||
continueInferiorInternal();
|
||||
return;
|
||||
}
|
||||
if (reason.isEmpty()) { // tbreak does that
|
||||
// For programs without -pthread under gdb <= 6.8.
|
||||
if (!inferiorPid())
|
||||
// 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
|
||||
|
Reference in New Issue
Block a user