summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Shorten sanitizer plugin namesPavel Labath2017-06-261-323/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* Upstreaming the UndefinedBehaviorSanitizerRuntime and ↵Kuba Mracek2017-06-161-7/+0
| | | | | | MainThreadCheckerRuntime plugins. llvm-svn: 305589
* Rename Error -> Status.Zachary Turner2017-05-121-2/+2
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move classes from Core -> Utility.Zachary Turner2017-02-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Use Timeout<> in EvaluateExpressionOptions classPavel Labath2016-12-061-2/+2
| | | | llvm-svn: 288797
* Support more report types in AddressSanitizerRuntime.cpp, re-word existing ones.Kuba Mracek2016-12-021-26/+41
| | | | | | | | In r288065, we added more report types into ASan that will be reported via the debugging API. This patch in LLDB provides human-friendly bug descriptions. This also improves wording on existing bug descriptions. Differential Revision: https://reviews.llvm.org/D27017 llvm-svn: 288535
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* Make lldb::Regex use StringRef.Zachary Turner2016-09-211-1/+2
| | | | | | | | | | This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-218/+215
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* [InstrumentationRuntime] Refactor the API (Part 2/N) (NFCI)Vedant Kumar2016-08-111-36/+10
| | | | | | | | | 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
* [InstrumentationRuntime] Refactor the API (Part 1/N) (NFCI)Vedant Kumar2016-08-111-26/+10
| | | | | | | | | | | | | | | | | 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
* [asan] Remove unused include (NFC)Vedant Kumar2016-08-051-1/+0
| | | | llvm-svn: 277837
* In AddressSanitizer and ThreadSanitizer, let's explicitly set the language ↵Kuba Brecka2016-07-061-0/+1
| | | | | | of the expression we're evaluating. llvm-svn: 274621
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-2/+2
| | | | llvm-svn: 270024
* Tentative fix (add `extern "C"` declarations to expression prefix) and ↵Kuba Brecka2016-04-071-5/+13
| | | | | | printing evaluation errors for AddressSanitizer (both MemoryHistoryASan.cpp and AddressSanitizerRuntime.cpp). Hopefully this will make the ASan testcases pass or at least the failure should be easier to diagnose. llvm-svn: 265651
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-291-1/+6
| | | | | | | | | | | | | setting to quietly apply fixits for those who really trust clang's fixits. Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present. <rdar://problem/25351938> llvm-svn: 264793
* This change introduces a "ExpressionExecutionThread" to the ThreadList. Jim Ingham2016-03-121-1/+1
| | | | | | | | | | | | | | | | | | | Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on behalf of the expression parser was using the currently selected thread. But sometimes, e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread we're running on, we instead set the context for the interpreter, and explicitly pass that to other callers. That wasn't getting communicated to these utility expressions, so they would run on some other thread instead, and that could cause a variety of subtle and hard to reproduce problems. I also went through the commands and cleaned up the use of GetSelectedThread. All those uses should have been trying the thread in the m_exe_ctx belonging to the command object first. It would actually have been pretty hard to get misbehavior in these cases, but for correctness sake it is good to make this usage consistent. <rdar://problem/24978569> llvm-svn: 263326
* The ASAN report fetching code had two latent bugs:Jim Ingham2016-01-151-2/+9
| | | | | | | | | | | | 1) It was forward declaring functions without 'extern "C"'. That used to work but only because of another bug in how we passes symbol only function names to the compiler and stopped working recently. 2) These forward declarations were in the body of the User Expression, and they actually need to go in the prefix file. <rdar://problem/24177689> llvm-svn: 257852
* Stop objects from keeping a strong reference to the process when they should ↵Greg Clayton2015-08-311-23/+38
| | | | | | have a weak reference. llvm-svn: 246488
* Improve check for ASAN callbacksTamas Berghammer2015-08-121-8/+5
| | | | | | | | | | | The ASAN callbacks are public symbols so we can search for them with reading only the symbol table (not the debug info). Whit this change the attach time for big executables with debug symbols decreased by a factor of ~4. Differential revision: http://reviews.llvm.org/D11384 llvm-svn: 244739
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-2/+2
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Fixed an issue with expressions that define types in the expression. We must ↵Greg Clayton2015-05-211-19/+27
| | | | | | | | currently touch the members of the struct in the right order or our ClangASTImporter::DeportType() will copy the resulting type into the target AST incorrectly. This is a work around for <rdar://problem/21049838> which the copy type issue so that it doesn't happen. <rdar://problem/20902950> llvm-svn: 237865
* Since the asan report function doesn't gather bp or sp, Jim Ingham2015-05-201-0/+4
| | | | | | | | | don't put those values in the Structured Data we make up from the report. <rdar://problem/21038887> llvm-svn: 237824
* Further reduce header footprint of Debugger.h.Zachary Turner2015-03-041-0/+1
| | | | llvm-svn: 231202
* Change AddressSanitzierRuntime to print its info message viaJason Molenda2014-12-091-14/+28
| | | | | | | | the Debugger's output stream instead of logging to the module. http://reviews.llvm.org/D6577 llvm-svn: 223826
* LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and ↵Kuba Brecka2014-10-101-0/+300
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
OpenPOWER on IntegriCloud