This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: Synth virtual time tick patch
> 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