fix raise_exception()

[d-a-v]

This is a proposal

It seems this has no visible effect:

__asm__ __volatile__ ("syscall"); // triggers gdb or does nothing

On panic/abort/assert called from user context, WDT happens due to the following while(1); and finally produces an exception with the right message (after the WDT reason and delay).
On ISR context, only the WDT reason is visible.

This commit permits to avoid WDT and show the right message from both user or ISR context.

Before #4482, *((int*)0)=0 was used to trigger an hardware exception (similar to the WDT exception we have now, also showing an additional message unrelated to the real cause).

On real hardware exception, raise_exception() is not called.

fixes #6283 (thanks @mhightower83)

[d-a-v]

This is tested with gdb:

• user exception in user context:
  gdb doesn't show the exact line,
  but that kind of exception is anyway displayed on console (panic/abort/assert)
• hardware exception in user context - ok
• user exception in sys context - ok
• hardware exception in sys context - ok

So there is room for improvement on gdb side (I'm not a specialist)

[earlephilhower]

I think that's exactly as it was for GDB. On assert/panic/etc. you get a breakpoint in the raise_exception() call and need to "up" one or two levels to get to the actual line of code (but it's still there in the stack so it's fully functional).

[earlephilhower]

Minor cleanings only. Looks good logically.

[earlephilhower]

LGTM now.

[devyte]

Overall, I'm ok with the approach, pending my minor comments. In essence, if there is a code path that calls raise_exception(), then set a global flag before manually calling __real_system_restart_local(), then interpret that flag first.
Of course, if syscall were to actually work as it's supposed to, it would be much better and standard, but I have no idea how to do that.
And great work figuring out this solution!

[devyte]

Nothing jumps out at me.
Out of curiosity, does this work correctly with exceptions enabled? (after they get fixed again)

[earlephilhower]

It should work w/C++ exceptions, should they get fixed at some point. Exceptions don't involve this bit at all unless they're uncaught, at which point panic() is called and an exception reason printed (__unhandled_exception).