Re: Synth virtual time tick patch

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    Andrew> Hi Bart
    Andrew> Please can you have a look at this patch and see if its OK
    Andrew> for inclusion.

    Andrew> I've added the option to use the virtual itimer instead of
    Andrew> the real timer. When the virtual timer is used, the idle
    Andrew> thread loops rather than doing select. Normally you don't
    Andrew> want this since it consumes cycles on the host OS, but i
    Andrew> found that gdb cannot single step. You hit n for next and
    Andrew> it runs until the next break point. My guess is that the
    Andrew> process receives a signal while halted. When it single
    Andrew> steps the signal handler is run which is messing up the
    Andrew> single step. Using the virtual timer means there is very
    Andrew> little chance a signal is pending when the process is
    Andrew> single stepped so single steps works.

    Andrew> By default the new behavior is disabled.

I am not sure exactly what is happening here.

gdb itself should not be doing anything special when the application
receives SIGALRM or SIGIO, according to the default handlers.

AFAIK single-stepping at the C level can be implemented in two
different ways. One approach is to single-step the cpu one instruction
at a time, and in the resulting trap check whether or not the desired
location in the C code has been reached. The other is to install a
temporary breakpoint and then just continue. I would have expected
that "next" was always implemented using a temporary breakpoint. If
so, any incoming signals and timeslicing should not cause a problem.
In due course the current thread will run again and hit the
breakpoint. As far as the user is concerned this will usually seem
instantaneous.

Instead I do see some strange behaviour, at least with one test
program I tried. Sometimes "next" works as expected, but at other
times I end up inside the SIGALRM signal handler where it makes a
system call cyg_hal_sys_gettimeofday(). This is somewhat different
from what you describe, although the underlying problem is probably
the same.

Rather than just switching to the itimer I think I want a better
understanding of what is going on, and just how gdb is interacting
with the application. In the very near future synthetic target
applications may start receiving SIGIO signals as well as SIGALRM,
and there will be no way of stopping those signals coming in at
inconvenient moments.

Bart