phycore_mpc5554 idle thread exits when GDB invoked

[Gedare Bloom]

On Tue, Jun 3, 2014 at 8:16 AM, Peter Dufault <dufault at hda.com> wrote:
> 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?
>
One thought is that when the debugger breaks, perhaps it is using the
wrong kind of exception on the target and instead of replaying the
instruction it broke on, it skips over it. Since the instruction is a
branch back in the normal implementation, you don't get the branch
back and instead wind up in the next chunk of code in the object file.
Whereas now that you wrapped a function, the instruction that gets
skipped could be one of the nops in this_is_a_hack.

-Gedare

> 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 <dufault at 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 at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel