This is the mail archive of the
mailing list for the GDB project.
Any solution to not being able to interrupt step in GDB ?
- From: Antony KING <antony dot king at st dot com>
- To: gdb at sourceware dot org
- Date: Wed, 27 Feb 2008 21:59:53 +0000
- Subject: Any solution to not being able to interrupt step in GDB ?
I am currently using a version of GDB 6.6 (utilising our own remote
target interface) and I am trying to come up with a solution to the
problem we are seeing with the "step" command.
The problem is that GDB is not making it easy :-) for me to interrupt
the target when a "step" command has been issued on a statement of the
while (okay) continue;
(where okay is a volatile that will be changed by an interrupt handler).
Please note that the above example is an illustration of a general
problem we encounter when debugging real-time multi-threaded embedded
applications with pre-emptive scheduling and interrupts.
GDB attempts to step the statement but the PC never falls outside the
bounds of the statement address range and so GDB is forever performing a
single instruction step.
As a result I can only interrupt the "step" command when I press Ctrl-C
while GDB executing target_wait(). If Ctrl-C is pressed outside of
target_wait() (which in my implementation provides its own SIGINT
handler), then GDB does not notice the event, as it is stuck in the
following loop in wait_for_inferior() because ecs->wait_some_more is
ecs->ptid = deprecated_target_wait_hook (ecs->waiton_ptid,
ecs->ptid = target_wait (ecs->waiton_ptid, ecs->wp);
/* Now figure out what to do with the result of the result. */
This means that the user has to continually press Ctrl-C in the hope of
hitting the sweet spot.
Is there any clean solution I can use which allows me to break out this
loop if there is a pending SIGINT event waiting to be processed ? There
seems a be a need for a way to "stop stepping" when Ctrl-C is pressed.
One thought I have is to fake a target SIGINT signal by checking for a
pending SIGINT event after returning from target_wait() and modifying
ecs before calling handle_inferior_event().
Of course the same issue arises when using the MI interface (with, for
example, Eclipse) but is worse since only a single stop request is issued.
I have seen that the subject has been raised here:
but this did not seem to end with a solution.
Any advice would be appreciated.