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_hdr have valid data
- The data in both sections seems to expect
RA/PC to be in a 0x00000000 - PROGRAM_SIZE range
- This causes issues with both
unwinding/libunwinding since they do not expect .text to be relocated
- A workaround for
unwinding is to manually patch RA/PC by subtracting 0x8804000
- 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
vaddr to be at 0x0
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.
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:
.eh_frame/.eh_frame_hdrhave valid dataRA/PCto be in a0x00000000 - PROGRAM_SIZErangeunwinding/libunwindingsince they do not expect.textto be relocatedunwindingis to manually patchRA/PCby subtracting0x8804000vaddrto be at0x0At this stage, I'm not sure how to proceed, as fixing up the
eh_framedata could be done during prx generation - but is likely to be a non-trivial amount of work. Similarly, forcing the linker to set avaddrof0x8804000for.textmight 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
libunwindor need nearly as much boilerplate.