Page MenuHomePhabricator

LLDB AddressSanitizer break on error and report data extraction
ClosedPublic

Authored by kubamracek on Oct 2 2014, 5:28 PM.

Details

Summary

This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.

More precisely this patch...

  1. adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
  2. an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
  3. adds a collection of these plugins into the Process class
  4. AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
  5. this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
  6. the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
  7. the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
  8. SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
  9. adds a test case for all of this

I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.

Diff Detail

Event Timeline

kubamracek updated this revision to Diff 14360.Oct 2 2014, 5:28 PM
kubamracek retitled this revision from to LLDB AddressSanitizer break on error and report data extraction.
kubamracek updated this object.
kubamracek edited the test plan for this revision. (Show Details)
kubamracek added reviewers: jasonmolenda, jingham.
kubamracek added a subscriber: Unknown Object (MLST).

On the other, I'm not sure about the new stop reason enum value (eStopReasonInstrumentation), maybe I should just reuse eStopReasonException. At least for AddressSanitizer, these stops practically *are* exceptions.

jingham edited edge metadata.Oct 7 2014, 12:11 PM

eStopReasonException is a Mach exception. When you hit a breakpoint the Mach Exception with type EXC_BREAKPOINT is the actual stop reason, but this gets translated to eStopReasonBreakpoint if it the stop address is one of our breakpoints. Similarly on Linux, you'd get an eStopReasonSignal/SIGTRAP, which would get translated to eStopReasonBreakpoint if the address was at one of our breakpoints. The eStopReasonInstrumentation is analogous. You stop for some system specific reason, which you then identify as an instrumentation stop, so you convert the stop reason from a general one to one specific to the event that occurred.

Jim

jasonmolenda edited edge metadata.Oct 10 2014, 3:37 PM

Looks good to me. It's not critical but AddressSanitizerRuntime::RetrieveReportData() is more expensive than it needs to be because it's compiling your expression every time. If this is going to be executed frequently, you'd want to use a ClangFunction - along the lines with how the SystemRuntimeMacOSX calls into libBacktraceRecording (although I did it poorly and I don't think I get the return type from the ClangFunction - I just extract it from memory, probably unnecessarily, I need to go back and look at that again.)

I don't think this code path will be hot enough to be performance sensitive, but that's the only comment I have. I would commit this patch and if you want to look at switching to a ClangFunction, do that after.

Landed in r219546!

kubamracek accepted this revision.Oct 13 2014, 9:27 AM
kubamracek added a reviewer: kubamracek.
This revision is now accepted and ready to land.Oct 13 2014, 9:27 AM
kubamracek closed this revision.Oct 13 2014, 9:27 AM