This is an archive of the discontinued LLVM Phabricator instance.

CrashReason: Add MTE tag check faults to the list of crash reasons.
ClosedPublic

Authored by pcc on Dec 17 2020, 3:39 PM.

Details

Summary

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.

Diff Detail

Event Timeline

pcc created this revision.Dec 17 2020, 3:39 PM
pcc requested review of this revision.Dec 17 2020, 3:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 17 2020, 3:39 PM

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.
(I have been following it from a distance but not sure of the status)

pcc updated this revision to Diff 313190.Dec 21 2020, 1:38 PM

Show fault address for SEGV_MTESERR

pcc added a comment.Dec 21 2020, 1:38 PM

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.
(I have been following it from a distance but not sure of the status)

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.

DavidSpickett added a comment.EditedDec 22 2020, 1:22 AM

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] ..."

labath accepted this revision.Dec 27 2020, 5:01 AM
This revision is now accepted and ready to land.Dec 27 2020, 5:01 AM
emaste added inline comments.Dec 27 2020, 10:33 AM
lldb/source/Plugins/Process/POSIX/CrashReason.cpp
62

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).

emaste added inline comments.Dec 27 2020, 1:35 PM
lldb/source/Plugins/Process/POSIX/CrashReason.cpp
62
This revision was landed with ongoing or failed builds.Dec 29 2020, 2:37 PM
This revision was automatically updated to reflect the committed changes.
pcc added inline comments.Dec 29 2020, 2:44 PM
lldb/source/Plugins/Process/POSIX/CrashReason.cpp
62

Makes sense, done.

For now I left SEGV_BNDERR as is, although it doesn't appear that any of FreeBSD, OpenBSD, NetBSD, illumos or XNU have defined anything besides SEGV_MAPERR and SEGV_ACCERR so it might be good to put SEGV_BNDERR under the #ifdef as well.

emaste added inline comments.Dec 31 2020, 12:01 PM
lldb/source/Plugins/Process/POSIX/CrashReason.cpp
62

What do you think about

#ifdef __linux__
#ifndef SEGV_MTEAERR
#define SEGV_MTEAERR 8
#endif

#ifdef SEGV_MTEAERR
  case SEGV_MTEAERR:
    return CrashReason::eAsyncTagCheckFault;
#endif

We're likely to have SEGV_MTEAERR in FreeBSD soon