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

Arm32 EABI exception handling #128156

Open
2 tasks
workingjubilee opened this issue Jul 24, 2024 · 3 comments
Open
2 tasks

Arm32 EABI exception handling #128156

workingjubilee opened this issue Jul 24, 2024 · 3 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-netbsd Operating system: NetBSD T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@workingjubilee
Copy link
Member

workingjubilee commented Jul 24, 2024

I am opening this issue to track work regarding improving Arm 32-bit EABI exception-handling. There are a few fixmes that were never addressed and some things that I found a bit unclear. These are currently mostly questions, and it is possible this issue may be resolved fully by merely answering the questions (and hopefully committing an answer somewhere).

  • How bad is reusing r12, anyways?
  • What's up with NetBSD?

Arm, GCC, exceptions, and r12

We find this comment in our source:

// The DWARF unwinder assumes that _Unwind_Context holds things like the function
// and LSDA pointers, however ARM EHABI places them into the exception object.
// To preserve signatures of functions like _Unwind_GetLanguageSpecificData(), which
// take only the context pointer, GCC personality routines stash a pointer to
// exception_object in the context, using location reserved for ARM's
// "scratch register" (r12).
uw::_Unwind_SetGR(context, uw::UNWIND_POINTER_REG, exception_object as uw::_Unwind_Ptr);
// ...A more principled approach would be to provide the full definition of ARM's
// _Unwind_Context in our libunwind bindings and fetch the required data from there
// directly, bypassing DWARF compatibility functions.

It's unclear what benefits this has, to me, and if our codegen backend could even exploit them, theoretically, if we did this. Mere correctness? Perhaps mere correctness is worth it, it might just be a fairly simple def.

NetBSD

According to this lovingly detailed commit message, NetBSD on 32-bit Arm using the EABI does not use the Arm EABI exception handling routines.

However, perhaps because it was not seen as relevant, it was not documented what it does use as its approach for unwinding. This is unfortunate, as we have recently seen Arm bugs on NetBSD that appear to be caused by assuming NetBSD on Arm must operate exactly like it does on x86, and discovering we are wrong, because of bugs or other reasons.

@he32 Do all NetBSD architectures use the same unwinding? Do we even unwind correctly on the not-so-x86 NetBSD architectures? Apparently not if this is to be believed? #96914

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 24, 2024
@workingjubilee workingjubilee added A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-netbsd Operating system: NetBSD T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jul 24, 2024
@he32
Copy link
Contributor

he32 commented Jul 24, 2024 via email

@workingjubilee
Copy link
Member Author

workingjubilee commented Jul 24, 2024

Yes! I do happen to ask incisive questions, and thank you for answering them! Even when you give an "I don't know", that is quite a lot better than having no idea whatsoever. At least then we know it is an unknown, and might cost effort to find an answer.

Fortunately I also have almost no such belief that things should be "self-evident from the code", especially when it is a matter of a complicated system interface. You will notice that I try to add documentation for later reference as I go: workingjubilee@fcf7539

@workingjubilee
Copy link
Member Author

Ooh, things get even more exciting soon! #130077

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-netbsd Operating system: NetBSD T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants