sim bug with resume after breakpoint in gdb

Doug Evans dje@google.com
Thu Nov 24 08:26:00 GMT 2011


On Fri, Nov 4, 2011 at 12:01 PM, Mike Stump <mikestump@comcast.net> wrote:
> 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.
>
> Thoughts?
>
> 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;

Hi.
I looked at this a bit.
It's been too long, and I'm not sure I understand
sim_events_preprocess well enough to be of much help.

I'd like to help fix this but this may take a couple of iterations.
First a question: when will last_cpu_nr ever be >= nr_cpus ?
How does that happen?

Second, the code in cgen-run.c:engine_run_n looks wrong.
When is next_cpu_nr ever reset to 0?
Am I missing something?

  while (1)
    {
      SIM_ENGINE_PREFIX_HOOK (sd);

      /* FIXME: proper cycling of all of them, blah blah blah.  */
      while (next_cpu_nr != nr_cpus)
        {
          SIM_CPU *cpu = STATE_CPU (sd, next_cpu_nr);

          (* engine_fns[next_cpu_nr]) (cpu);
          ++next_cpu_nr;
        }

      SIM_ENGINE_POSTFIX_HOOK (sd);

      /* process any events */
      if (sim_events_tick (sd))
        sim_events_process (sd);
    }



More information about the Gdb-patches mailing list