Page MenuHomeFreeBSD

arm64: handle watchpoint exceptions from EL0
ClosedPublic

Authored by mhorne on Feb 9 2021, 8:44 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 15, 3:20 AM
Unknown Object (File)
Fri, Nov 15, 2:56 AM
Unknown Object (File)
Fri, Nov 15, 12:42 AM
Unknown Object (File)
Wed, Nov 6, 12:31 PM
Unknown Object (File)
Fri, Nov 1, 1:06 AM
Unknown Object (File)
Wed, Oct 23, 11:14 PM
Unknown Object (File)
Sun, Oct 20, 11:14 PM
Unknown Object (File)
Oct 14 2024, 8:15 PM

Details

Test Plan

Triggering an EL0 watchpoint generates SIGTRAP after this patch.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mhorne requested review of this revision.Feb 9 2021, 8:44 PM
This revision is now accepted and ready to land.Feb 9 2021, 9:06 PM
sys/arm64/arm64/trap.c
539

I'm not sure here and I can't figure out the abstractions in Linux code but on Linux I'm getting a SIGTRAP with si_addr pointing to the watched memory rather than the instruction, and LLDB uses that to identify which watchpoint was hit. Do you have any suggestion if I can determine that any other way?

sys/arm64/arm64/trap.c
539

Hmm. Returning the watched address in si_addr does seem more useful. I don't think there is any other simple way to determine which watchpoint triggered the exception, so we can probably switch over to this.

My only reservation is that FreeBSD/amd64 does not appear to behave this way, and it returns the trapping instruction address in si_addr.

sys/arm64/arm64/trap.c
539

Indeed it doesn't. We are working around that by checking DR7 directly.

Pass the value of the Fault Address Register to si_addr. This contains the address that triggered the watchpoint.

This revision now requires review to proceed.Feb 12 2021, 11:50 PM

Thanks, I was able to get working hardware watchpoints with this patch.

Update siginfo(3) man page to note the differing behaviour of si_addr.

jhb added inline comments.
share/man/man3/siginfo.3
221–224

I'm not sure I would keep the arm64 sentence as we don't document the MD behaviors for other signals here but instead just use "may" to indicate it can vary.

This revision is now accepted and ready to land.Feb 16 2021, 8:33 PM
This revision was automatically updated to reflect the committed changes.