Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
Marco Bubke
flatpak-qt-creator
Commits
0d3ca6da
Commit
0d3ca6da
authored
Nov 23, 2010
by
hjk
Browse files
debugger: make attach to running process stop the process (again)
parent
7812c958
Changes
3
Hide whitespace changes
Inline
Side-by-side
src/plugins/debugger/gdb/attachgdbadapter.cpp
View file @
0d3ca6da
...
...
@@ -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
)
...
...
src/plugins/debugger/gdb/gdbengine.cpp
View file @
0d3ca6da
...
...
@@ -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",
...
...
src/plugins/debugger/gdb/gdbengine.h
View file @
0d3ca6da
...
...
@@ -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
);
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment