LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
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...
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
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
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
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
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)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
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.
Kuba
llvm-svn: 219546
2014-10-11 07:43:03 +08:00
|
|
|
//===-- InstrumentationRuntime.cpp ------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
2016-02-18 08:10:17 +08:00
|
|
|
//===---------------------------------------------------------------------===//
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
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...
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
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
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
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
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)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
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.
Kuba
llvm-svn: 219546
2014-10-11 07:43:03 +08:00
|
|
|
|
2016-02-18 08:10:17 +08:00
|
|
|
// C Includes
|
|
|
|
// C++ Includes
|
|
|
|
// Other libraries and framework includes
|
|
|
|
// Project includes
|
2016-09-07 04:57:50 +08:00
|
|
|
#include "lldb/Target/InstrumentationRuntime.h"
|
2016-08-12 01:28:37 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/ModuleList.h"
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
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...
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
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
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
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
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)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
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.
Kuba
llvm-svn: 219546
2014-10-11 07:43:03 +08:00
|
|
|
#include "lldb/Core/PluginManager.h"
|
2016-08-12 01:28:37 +08:00
|
|
|
#include "lldb/Core/RegularExpression.h"
|
2016-09-07 04:57:50 +08:00
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/lldb-private.h"
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
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...
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
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
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
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
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)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
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.
Kuba
llvm-svn: 219546
2014-10-11 07:43:03 +08:00
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void InstrumentationRuntime::ModulesDidLoad(
|
|
|
|
lldb_private::ModuleList &module_list, lldb_private::Process *process,
|
|
|
|
InstrumentationRuntimeCollection &runtimes) {
|
|
|
|
InstrumentationRuntimeCreateInstance create_callback = nullptr;
|
|
|
|
InstrumentationRuntimeGetType get_type_callback;
|
|
|
|
for (uint32_t idx = 0;; ++idx) {
|
|
|
|
create_callback =
|
|
|
|
PluginManager::GetInstrumentationRuntimeCreateCallbackAtIndex(idx);
|
|
|
|
if (create_callback == nullptr)
|
|
|
|
break;
|
|
|
|
get_type_callback =
|
|
|
|
PluginManager::GetInstrumentationRuntimeGetTypeCallbackAtIndex(idx);
|
|
|
|
InstrumentationRuntimeType type = get_type_callback();
|
|
|
|
|
|
|
|
InstrumentationRuntimeCollection::iterator pos;
|
|
|
|
pos = runtimes.find(type);
|
|
|
|
if (pos == runtimes.end()) {
|
|
|
|
runtimes[type] = create_callback(process->shared_from_this());
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
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...
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
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
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
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
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)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
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.
Kuba
llvm-svn: 219546
2014-10-11 07:43:03 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
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...
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
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
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
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
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)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
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.
Kuba
llvm-svn: 219546
2014-10-11 07:43:03 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void InstrumentationRuntime::ModulesDidLoad(
|
|
|
|
lldb_private::ModuleList &module_list) {
|
|
|
|
if (IsActive())
|
|
|
|
return;
|
2016-08-12 01:28:37 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (GetRuntimeModuleSP()) {
|
|
|
|
Activate();
|
|
|
|
return;
|
|
|
|
}
|
2016-08-12 01:28:37 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
module_list.ForEach([this](const lldb::ModuleSP module_sp) -> bool {
|
|
|
|
const FileSpec &file_spec = module_sp->GetFileSpec();
|
|
|
|
if (!file_spec)
|
|
|
|
return true; // Keep iterating.
|
2016-08-12 01:28:37 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const RegularExpression &runtime_regex = GetPatternForRuntimeLibrary();
|
|
|
|
if (runtime_regex.Execute(file_spec.GetFilename().GetCString()) ||
|
|
|
|
module_sp->IsExecutable()) {
|
|
|
|
if (CheckIfRuntimeIsValid(module_sp)) {
|
|
|
|
SetRuntimeModuleSP(module_sp);
|
|
|
|
Activate();
|
|
|
|
return false; // Stop iterating, we're done.
|
|
|
|
}
|
|
|
|
}
|
2016-08-12 01:28:37 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
});
|
2016-08-12 01:28:37 +08:00
|
|
|
}
|
|
|
|
|
2016-04-11 02:57:38 +08:00
|
|
|
lldb::ThreadCollectionSP
|
2016-09-07 04:57:50 +08:00
|
|
|
InstrumentationRuntime::GetBacktracesFromExtendedStopInfo(
|
|
|
|
StructuredData::ObjectSP info) {
|
|
|
|
return ThreadCollectionSP(new ThreadCollection());
|
2016-04-11 02:57:38 +08:00
|
|
|
}
|