Any solution to not being able to interrupt step in GDB ?

[Antony KING <antony.king@st.com>]

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->wp);
        else
          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)
          break;
      }

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:

    http://sourceware.org/ml/gdb/2007-03/msg00228.html

but this did not seem to end with a solution.
]

Any advice would be appreciated.

Cheers,

Antony.