Fix Panic/Exception Support #165
Description
It seems with a recent nightly change panic/exception support has broken and resulted in any/all panics causing an invalid memory access deep within libunwind.
I have invested a couple of weeks investigating, and unfortunately haven't been able to find an easy solution to the problem. Though I have made some findings in the process which I'll dump below:
- It seems that
.eh_frame/.eh_frame_hdrhave valid data - The data in both sections seems to expect
RA/PCto be in a0x00000000 - PROGRAM_SIZErange - This causes issues with both
unwinding/libunwindingsince they do not expect.textto be relocated - A workaround for
unwindingis to manually patchRA/PCby subtracting0x8804000 - This causes stack traces/stack unwinding to work, but not raising exceptions, due to other pointers in both sections being incorrect (leading to an invalid memory access)
- I'm not sure if this is a linker bug, or an issue with relocations, as we technically want/need
vaddrto be at0x0
At this stage, I'm not sure how to proceed, as fixing up the eh_frame data could be done during prx generation - but is likely to be a non-trivial amount of work. Similarly, forcing the linker to set a vaddr of 0x8804000 for .text might fix this issue as well, but also means a non-trivial amount of work. I'm not familiar with how the PSP relocates executables at runtime, so I'm not confident in either of these approaches being a one-size-fits-all solution.
If we're able to resolve the issue with frame data, we can also switch to unwinding as I've done here + upstream support to std similar to xous. Which will significantly reduce the complexity of panic handling, as we won't need to ship a patched libunwind or need nearly as much boilerplate.