Exception handler improvements

[AntonioND]

Currently, the ARM9 exception handler of libnds does a reasonable job at helping you find the cause of a data abort or undefined instruction exception. However, there are multiple ways we could improve exception handling support:

• Only one screen is used, the one that displays the values of all the registers and a bit of the stack. We can add a stack trace to the other screen (even only the addresses are okay, we don't need function names for it to be useful).
• We could also send the text output to the no$gba console API so that it's easier to copy-paste the text out of no$gba and melonDS.
• We should add a handler to the ARM7 side of libnds. Maybe it could send a FIFO message to the ARM9 with the information so that the ARM9 handles it, or it could handle it in the ARM7 and print the output to the no$gba console (but then you wouldn't get anything useful in real hardware).

[asiekierka]

I think the first question to ask is "how much of the environment can the exception handler assume to be intact?". That will inform some of the other decisions.

We can add a stack trace to the other screen (even only the addresses are okay, we don't need function names for it to be useful).

The ARM backend of GCC has a nice trick called -mpoke-function-name. This could allow placing function names in debug builds with very little hassle for the library, and could be one approach to making this more user-friendly.

[AntonioND]

I would assume that anything can be broken, but the stack trace unwind could check if the addresses are in valid RAM before following them, etc.

That is a nice trick indeed.

There is some prior art in doing this, too: http://consoledev.de/project/stack-trace-for-nds/ We can't use the code from that link directly because it doesn't have any license, but maybe we can contact the author and ask about it.