Re: Accessing ESR from signal handlers on AArch64

(fwiw, i recommend "silence" as a response being "noone's doing it,
please go do it and ask questions" :-) )


-a

On Wed, 25 Feb 2026 at 12:09, Alex Arslan <[email protected]> wrote:
>
> 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