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)


Stephane Carrez wrote:
> 
> 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.

Sorry, I'm confused.  A quick grep over src/* shows the fr30, i960,
m32r, mips and v850 all calling that function so the code will need to
handle the restart case.

To explain a restart.  It is called when it is just too complex to try
to back out of a hole that the code has dug.  It originaed in the PPC
(which still doesn't use sim/common) where it was used when implementing
VM.  The code was greatly simplified by, when a page fault occurs, doing
the fixup and then re-starting the simulator.

With respect to the bug.  I suspect that:

	if (xx->stop != NULL && single stepping)
	  xx->stop = create stop breakpoint()

will handle both cases.

	Andrew

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