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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.