This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [Patch 6/7]: 68HC11 port of gdb (sim-misc single step fix)
Hi!
Andrew Cagney a écrit :
> [...]
> > ssignal does not seem to be ever used. It seemed to be ignored in most
> > simulators (and in sim_engine_run).
>
> >From memory, siggnal will be non-zero, if, from the GDB cli, someone
> enters:
>
> (gdb) signal NNNN
>
> Most simulators ignore it because most don't allow trapping of system
> interrupts.
>
> > I don't reach that point anyway when the problem occurs. I don't return
> > from 'sim_events_preprocess' because it calls 'sim_engine_halt' that longjumps
> > to return (due to single step event we just scheduled).
>
> What about a sim_engine_restart()?
>
> Andrew
It's not called.
Here is the backtrace to prove my explanation (sim-resume.c correspond to
the file in gdb 5.0).
(top-gdb) where
#0 sim_engine_halt (sd=0x820f020, last_cpu=0x0, next_cpu=0x0, cia=0,
reason=sim_stopped, sigrc=66) at ./../common/sim-engine.c:72
#1 0x81144ed in has_stepped (sd=0x820f020, data=0x820f020)
at ./../common/sim-resume.c:31
#2 0x810c1b3 in sim_events_process (sd=0x820f020)
at ./../common/sim-events.c:1162
#3 0x810b597 in sim_events_preprocess (sd=0x820f020, events_were_last=1,
events_were_next=1) at ./../common/sim-events.c:1063
#4 0x8114619 in sim_resume (sd=0x820f020, step=1, siggnal=0)
at ./../common/sim-resume.c:69
#5 0x80d5932 in gdbsim_wait (pid=-1, status=0xbffff1c8)
at remote-sim.c:686
And in 'sim_events_process', I have:
(top-gdb) p *events
$7 = {
nr_ticks_to_process = 6,
queue = 0x822a4c0,
watchpoints = 0x0,
watchedpoints = 0x0,
free_list = 0x0,
work_pending = 0,
held = 0x8224370,
nr_held = 0,
elapsed_wallclock = 260,
resume_wallclock = 491,
time_of_event = 499728,
time_from_event = 1,
trace = 0
}
I think you can reproduce on any simulator by replacing the sim_events_tick()
with sim_events_tickn(sd, 2). Put a breakpoint, continue to hit the breakpoint
and then stepi. From gdb, you will stay at the same pc.
Once the problem occurs, it remains because the 'nr_ticks_to_process'
are not consumed immediately. They are cleared only after all the event
handler return (last lines of sim_events_process).
In the single-step event case, we don't return because 'has_stepped'
calls longjumps....
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France