I tried to figure out why I don't see any issues during normal debugging when I
set breakpoints and then start GDB, I only have a problem when I hit ^C to
enter GDB. Since bsp_idle_thread() is unusual in that the generated code has no
return from subroutine:
0006ef44 <bsp_idle_thread>:
6ef44: 48 00 00 00 b 6ef44 <bsp_idle_thread>
I hacked the bsp_idle_thread to be the following. Now when I break into the
debugger with ^C I'm in the "this_is_a_hack()" function, and I do not have any
issues with pending interrupts and then winding up returning from
bsp_idle_thread() and then calling bsp_reset().
Anyone have any ideas as to what could be causing this odd behavior?
void __attribute__ ((noinline)) this_is_a_hack()
{
volatile int i;
for (i = 0; i < 1000000; i++) {
}
}
void *bsp_idle_thread(uintptr_t arg)
{
while (true) {
this_is_a_hack();
}
return NULL;
}
On Jun 3, 2014, at 07:19 , Peter Dufault <dufa...@hda.com> wrote:
> I stumbled on something. If I disconnect the ethernet it will work OK. I
> also notice that if I hit a return at the serial console while within GDB it
> will do the same thing. Something about trying to resume with an interrupt
> pending is screwing things up. It mustn't be clock tick interrupts, though,
> or maybe the clock is stopped and restarted but the other interrupts remain
> pending.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
