This is the mail archive of the 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]
Other format: [Raw text]

sim bug with resume after breakpoint in gdb

So, when I resume after a break point in gdb using my sim target, I hit an assert:

sim_events_preprocess (SIM_DESC sd,
                       int events_were_last,
                       int events_were_next)
  sim_events *events = STATE_EVENTS (sd);
  if (events_were_last)
      /* Halted part way through event processing */
      ASSERT (events->nr_ticks_to_process != 0);

Now, certainly my port is slightly wrong someplace, as other ports I presume don't abort.  I've found the patch at the end fixes this, but, since other ports don't need it, it would seem to be wrong.  So, do you have pointers to the right place to fix this, if it is wrong?  If not, is this the best way to fix it?

I've wired up my simulator to be able to simulate more than a few cores, I don't expect this will the last patch in the area, as I bet this doesn't resume the right core when doing multiple cores.  But when doing 1 core, the below is just fine.


Index: sim/common/cgen-run.c
--- sim/common/cgen-run.c	(revision 1903)
+++ sim/common/cgen-run.c	(working copy)
@@ -102,6 +102,9 @@ sim_resume (SIM_DESC sd, int step, int s
 		       : 8); /*FIXME: magic number*/
       int fast_p = STATE_RUN_FAST_P (sd);
+      if (STATE_EVENTS (sd)->nr_ticks_to_process == 0 &&
+	  last_cpu_nr >= nr_cpus)
+	last_cpu_nr = 0;
       sim_events_preprocess (sd, last_cpu_nr >= nr_cpus, next_cpu_nr >= nr_cpus);
       if (next_cpu_nr >= nr_cpus)
 	next_cpu_nr = 0;

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