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)
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [Patch 6/7]: 68HC11 port of gdb (sim-misc single step fix)
- From: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>
- Date: Fri, 28 Jul 2000 23:50:38 +0200
- CC: Stephane Carrez <Stephane dot Carrez at free dot fr>, gdb-patches at sourceware dot cygnus dot com
- References: <39568A82.A0B2BFEB@free.fr> <3980227F.A6FC263B@cygnus.com>
Hi!
Andrew Cagney a écrit :
>
> Stephane Carrez wrote:
>
> > 2000-06-25 Stephane Carrez <Stephane.Carrez@worldnet.fr>
> >
> > * nrun.c (main): Print the simulator statistics only in
> > verbose mode.
> > * hw-properties.h (hw_find_integer_array_property): Fix
> > prototype (use signed_cell).
>
> I've committed these, thanks.
>
> > * sim-resume.c (sim_resume): Install the single step event
> > after having processed some current pending events. It may happen
> > that some ticks are not yet processed after a break/single step
> > command from GDB. In that case, installing the single step event
> > before processing pending events will activate the single step
> > without actually having executed any instruction.
>
> I don't think this is right. When the simulator does a restart, a
> second has_stepped event would be scheduled and the first would be lost.
>
Yes but I have another problem.
For my simulator, the number of ticks is advanced at each instruction by
the number of cycles the instruction takes. I have instructions that
can take 4 cycles up to 70 cycles. [I'm doing this to keep the simulator
behavior as close as possible to reality. The timer and all other devices
are in sync with the cpu.]
After each instruction the number of ticks is incremented with 'sim_events_tickn'
by the number of cycles the instruction took. Sometimes all the ticks are
taken into account, and sometimes some of them are saved in 'nr_ticks_to_process'.
If this happens we process a pending event. Such event stops the simulator
(for example because it was a single step). So, at that point,
nr_ticks_to_process != 0.
Now, next time I enter in 'sim_resume', we schedule a single step event for
tick 1. In general this is the next one. We then call 'sim_events_preprocess'.
Here we rememeber that we have some 'nr_ticks_to_process' and
we process them. Since the single step event is next (because at T+1),
it is processed and we stop the simulator (before having restarted it!!).
The fix I suggest consists in installing the single step event after we
have processed the pending ticks in 'nr_ticks_to_process'. By doing so,
the pending ticks in 'nr_ticks_to_process' don't break the single step.
> Andrew
>
> > diff -Nrup --exclude-from=gdb-exclude.lst /src/gnu/cygnus/gdb/sim/common/sim-resume.c gdb/sim/common/sim-resume.c
> > --- /src/gnu/cygnus/gdb/sim/common/sim-resume.c Mon Jul 12 13:14:09 1999
> > +++ gdb/sim/common/sim-resume.c Mon Feb 21 09:00:23 2000
> > @@ -51,8 +51,6 @@ sim_resume (SIM_DESC sd,
> > sim_events_deschedule (sd, engine->stepper);
> > engine->stepper = NULL;
> > }
> > - if (step)
> > - engine->stepper = sim_events_schedule (sd, 1, has_stepped, sd);
> >
> > sim_module_resume (sd);
> >
> > @@ -69,6 +67,9 @@ sim_resume (SIM_DESC sd,
> > sim_events_preprocess (sd, last_cpu_nr >= nr_cpus, next_cpu_nr >= nr_cpus);
> > if (next_cpu_nr >= nr_cpus)
> > next_cpu_nr = 0;
> > +
> > + if (step)
> > + engine->stepper = sim_events_schedule (sd, 1, has_stepped, sd);
> >
> > /* Only deliver the siggnal ]sic] the first time through - don't
> > re-deliver any siggnal during a restart. */
>
> Note the comment about siggnals[sic].
>
> Andrew
ssignal does not seem to be ever used. It seemed to be ignored in most
simulators (and in sim_engine_run).
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).
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