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 :
> [...]
> > 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

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