This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [Patch 6/7]: 68HC11 port of gdb (sim-misc single step fix)


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]