You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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/needvaddr 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.
The text was updated successfully, but these errors were encountered:
@overdrivenpotato I've pinged you and Artyom a few times on Discord about this, but pinging you here just so you can get a nice high level overview of the issue. I think I'm going to resume looking at vfpu support for now, since I've run into a roadblock with this one. 🙂
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_hdr
have valid dataRA
/PC
to be in a0x00000000 - PROGRAM_SIZE
rangeunwinding
/libunwinding
since they do not expect.text
to be relocatedunwinding
is to manually patchRA
/PC
by subtracting0x8804000
vaddr
to 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 avaddr
of0x8804000
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.The text was updated successfully, but these errors were encountered: