This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
following form:

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
always TRUE:

   while (1)
       if (deprecated_target_wait_hook)
         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.  */
       handle_inferior_event (ecs);

       if (!ecs->wait_some_more)

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]