Re: Accessing ESR from signal handlers on AArch64

> On Feb 28, 2026, at 12:14 PM, Warner Losh <[email protected]> wrote:
> 
> 
> 
> On Sat, Feb 28, 2026 at 1:07 PM Alex Arslan <[email protected] <mailto:[email protected]>> wrote:
>> 
>> 
>> > On Feb 27, 2026, at 10:00 AM, Adrian Chadd <[email protected] <mailto:[email protected]>> wrote:
>> > 
>> > (fwiw, i recommend "silence" as a response being "noone's doing it,
>> > please go do it and ask questions" :-) )
>> 
>> Noted, thank you! I've opened a pull request on GitHub with the described
>> changes: https://github.com/freebsd/freebsd-src/pull/2053. If it would be
>> more conducive to review/discussion to have that in Phabricator rather than
>> GitHub, I can close that pull request and resubmit to Phabricator, though
>> it seems Andrew Turner was already auto-pinged for review on GitHub.
> 
> GitHub is fine. This change is well suited to github: It looks good to go, it looks like
> we're binary compatible, it's small and easy to digest, and the reviewer is
> active enough on github.

Great! I appreciate you taking a look. :)

I should note that I was hoping to be able to rely on the CI checks that
run on GitHub PRs, as my only AArch64 system has insufficient resources to
build FreeBSD from source, but it seems the project has run out of Cirrus
CI credits... Apologies if I've committed the cardinal sin of open source
contribution.

> Bonus points if this worked in the linuxulator and bsd-user though :).

If bsd-user here is referring to qemu-bsd-user, I think analogous changes
to those in my PR plus some previous changes (e.g., commit f17e4f0 which
added `tf_esr` to `struct trapframe`) could work? Unfortunately I'm not
sure about Linuxulator though.

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