As of Linux 5.10, the kernel may report either of the two following
crash reasons:
- SEGV_MTEAERR: async MTE tag check fault
- SEGV_MTESERR: sync MTE tag check fault
Teach LLDB about them.
Differential D93495
CrashReason: Add MTE tag check faults to the list of crash reasons. pcc on Dec 17 2020, 3:39 PM. Authored by
Details As of Linux 5.10, the kernel may report either of the two following
Teach LLDB about them.
Diff Detail
Event TimelineComment Actions I assume that the signal displays without tag bits just like any other SEGV? I was thinking about testing but I don't see any tests for specific signals so it would only be needed if your change to add the tag bits to siginfo has gone in. Comment Actions With 5.10 the tag bits don't appear but with the latest version of my patch series, which is due to land in 5.11, the tag bits will appear in si_addr in the siginfo retrieved via ptrace(PTRACE_GETSIGINFO) and therefore will appear in the fault address displayed by the debugger. The tag bits are only hidden from signal handlers, and then only if SA_EXPOSE_TAGBITS is clear, so they will be exposed to ptrace no matter whether the debuggee has SA_EXPOSE_TAGBITS clear or set in its signal handler. Note that the tag bits will be exposed for all faults with a fault address, not just SEGV_MTESERR (though with SEGV_MTESERR we only get the low nibble of the tag due to hardware limitations). I verified all of this behavior in FVP and also noticed that I didn't add a line of code here that makes the fault address visible in the sync tag check fault case so I've now added it. Comment Actions Great, thanks for the explanation. I don't think this needs a test since (for now) it acts just like existing signals. The change looks good to me but @labath should approve since I don't know all the signal handling details. Edit: one thing, the commit message should include a tag at least for lldb, e.g. "[lldb][AArch64] ..."
|
This should perhaps include an #ifdef LINUX(sp?) somehow, since 8 and 9 are not necessarily MTEAERR / MTESERR on all POSIXy systems (although that said I'm planning to reserve 8 and 9 on FreeBSD to match).