Accessing ESR from signal handlers on AArch64
Alex Arslan <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.hackers |
|---|---|
| Message-ID | <[email protected]> |
Hello, Currently there's no way to access the exception syndrome register (ESR) on AArch64 from a signal handler. Nearly 10 years ago, this was "expected to be fixed soon"[1]; is that still on anybody's radar? In 2019, a patch was submitted by a contributor to expose ESR via `mcontext_t`[2], but that has had no comments to date. I reached out to the author and it sounds like she isn't planning to push on that revision. I would be happy to help make this happen, but I would need some handholding, and I don't want to duplicate effort if somebody else is already planning to take it on. From what I understand, the way to go about this would be to: - Update `struct __mcontext` to include a new `__register_t` field `mc_esr` - Reduce the size of `mc_spare` by 1 to account for the addition - Put `mc_esr` between `mc_ptr` and `mc_spare` to avoid affecting the ABI - Define a new bitmask `_MC_ESR_VALID` to set for `mc_flags`, analogous to the existing `_MC_FP_VALID` for `mc_fpregs` - In `sendsig`, populate the `struct trapframe` field `tf_esr` with the register value using `READ_SPECIALREG(esr_el1)` - In `get_mcontext`, set `mc_esr` to `tf_esr` and update `mc_flags` - In `set_mcontext`, set `tf_esr` to `mc_esr` if indicated by `mc_flags` Is that correct? Are there any steps or changes there that are missing? I'm not clear on whether it's appropriate to do so in the FreeBSD source tree or if it should first go into upstream LLVM, but the compiler-rt sanitizers could be updated to grab `mc_esr` via `ucontext_t` on FreeBSD so that write vs. read faults may be differentiated. The Julia programming language performs a similar query to the sanitizers, checking ESR on AArch64 to determine whether a `SIGSEGV` occurred due to a bad write and generating an appropriate runtime exception. On FreeBSD AArch64, we can't determine this, so we end up in the state of "well, there was a segfault and we haven't otherwise handled it, so RIP your process." (Addressing this is my motivation for pursuing the change described here.) Thanks! [1]: https://reviews.llvm.org/D32172 [2]: https://reviews.freebsd.org/D20838