This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
sim bug with resume after breakpoint in gdb
- From: Mike Stump <mikestump at comcast dot net>
- To: gdb-patches at sourceware dot org
- Date: Fri, 4 Nov 2011 12:01:24 -0700
- Subject: 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.
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;