Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Panic/Exception Support #165

Open
SK83RJOSH opened this issue Jan 21, 2024 · 1 comment
Open

Fix Panic/Exception Support #165

SK83RJOSH opened this issue Jan 21, 2024 · 1 comment

Comments

@SK83RJOSH
Copy link
Contributor

SK83RJOSH commented Jan 21, 2024

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.

@SK83RJOSH
Copy link
Contributor Author

@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. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant