| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The new UndefinedBehaviorSanitizer plugin was breaking file path length
limits, because it's (fairly long name) appears multiple times in the
path. Cmake ends up putting the object file at path
tools/lldb/source/Plugins/InstrumentationRuntime/UndefinedBehaviorSanitizer/CMakeFiles/lldbPluginInstrumentationRuntimeUndefinedBehaviorSanitizer.dir/UndefinedBehaviorSanitizerRuntime.cpp.obj
which is 191 characters long and very dangerously close to the 260
character path limit on windows systems (also, just the include line for
that file was breaking the 80 character line limit).
This renames the sanitizer plugins to use shorter names (asan, ubsan,
tsan). I think this will still be quite understandable to everyone as
those are the names everyone uses to refer to them anyway.
Reviewers: zturner, kubamracek, jingham
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34553
llvm-svn: 306278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
| |
|
|
|
|
|
|
|
| |
Factor out some common logic used to find the runtime library in a list
of modules.
Differential Revision: https://reviews.llvm.org/D23150
llvm-svn: 278368
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adapters for instrumentation runtimes have to do two basic things:
1) Load a runtime library.
2) Install breakpoints in that library.
This logic is duplicated in the adapters for asan and tsan. Factor it
out and document bits of it to make it easier to add new adapters.
I tested this with check-lldb, and double-checked
testcases/functionalities/{a,t}san.
Differential Revision: https://reviews.llvm.org/D23043
llvm-svn: 278367
|
| |
|
|
| |
llvm-svn: 277359
|
| |
|
|
|
|
|
|
| |
source/Plugins; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13916
llvm-svn: 250872
|
| |
|
|
|
|
| |
have a weak reference.
llvm-svn: 246488
|
|
|
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
|
