Re: Synth virtual time tick patch

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

> 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.

Yes, thats different to what i see. I suppose it could be a difference
in the gdb version. It looks like our Debian system has quite an old one.

:~$ gdb -v 
GNU gdb 19990928

Although i do see the same problem with the more up to date GNU gdb
4.18-ecos-99r1-001005 (The latest ARM toolchain we received, compile
for i686-pc-linux-gnu.)

Humm, interesting. man ptrace says:

       PTRACE_SYSCALL, PTRACE_SINGLESTEP
              Restarts the stopped child as for PTRACE_CONT,  but
              arranges  for  the  child to be stopped at the next
              entry to or exit from a system call, or after  exe­
              cution of a single instruction, respectively.  (The
 
 
 
Linux 2.2.10             7 November 1999                        2
 
 
 
 
 
PTRACE(2)           Linux Programmer's Manual           PTRACE(2)
 
 
              child will also, as usual, be stopped upon  receipt
              of  a  signal.)  From the parent's perspective, the
              child will appear to have been stopped  by  receipt
              of a SIGTRAP.  So, for PTRACE_SYSCALL, for example,
              the idea is to inspect the arguments to the  system
              call   at   the   first   stop,   then  do  another
              PTRACE_SYSCALL and inspect the return value of  the
              system call at the second stop.  (addr is ignored.)
 
The bit in () is interesting and fits with what i see and what my fix
works around.

> 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.

Great. I've never had the time nor do i have knowledge of the insides
of gdb to look at this. Also I don't particularly like my solution
because it spins, but its the best solution i have at the moment.

        Andrew