summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression
Commit message (Collapse)AuthorAgeFilesLines
...
* Move many other files from Core -> Utility.Zachary Turner2017-03-061-1/+1
| | | | llvm-svn: 297043
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-045-7/+7
| | | | llvm-svn: 296943
* Fix DataExtractor failures.Zachary Turner2017-03-031-13/+0
| | | | | | | Some code that doesn't get compiled on Windows had some references that needed updating, and I missed those. llvm-svn: 296930
* Isolate Target-specific functionality of DataExtractor.Zachary Turner2017-03-031-34/+30
| | | | | | | | | | | | | | | | In an effort to move the various DataBuffer / DataExtractor classes from Core -> Utility, we have to separate the low-level functionality from the higher level functionality. Only a few functions required anything other than reading/writing raw bytes, so those functions are separated out into a more appropriate area. Specifically, Dump() and DumpHexBytes() are moved into free functions in Core/DumpDataExtractor.cpp, and GetGNUEHPointer is moved into a static function in the only file that it's referenced from. Differential Revision: https://reviews.llvm.org/D30560 llvm-svn: 296910
* Move Log from Core -> Utility.Zachary Turner2017-03-0312-12/+12
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-142-2/+2
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Move classes from Core -> Utility.Zachary Turner2017-02-029-14/+14
| | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Add accurate dependency specificationsChris Bieneman2017-01-311-0/+14
| | | | | | | | | | | | | | | | | Summary: This patch adds accurate dependency specifications to the mail LLDB libraries and tools. In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way. For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up. Reviewers: labath, zturner Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell Differential Revision: https://reviews.llvm.org/D29333 llvm-svn: 293686
* Make lldb -Werror clean for -Wstring-conversionDavid Blaikie2017-01-061-19/+17
| | | | | | | | | Also found/fixed one bug identified by this warning in RenderScriptx86ABIFixups.cpp where a string literal was being used in an effort to provide a name for an instruction/register, but was instead being passed as the bool 'isVolatile' parameter. llvm-svn: 291198
* Silence some -Wstring-conversion warningsPavel Labath2017-01-051-1/+1
| | | | | | | | lldbassert(!"foo") -> lldbassert(0 && "foo") In one case, this actually detected a logic error in the assertion (missing !). llvm-svn: 291102
* Expression evaluation for overloaded C functions (redux)Luke Drummond2016-12-191-16/+3
| | | | | | | | | | | | | | | | | | | This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored to properly substitute primitive types using a hook in the itanium demangler, and updated after the previous patch went stale The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement primitive type parameter as before but parses it using the FastDemangler, which has been modified to be able to notify clients of parse events (primitive types at this point). Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so that we don't try and resolve the same invalid candidate multiple times. Differential Revision: https://reviews.llvm.org/D27223 Subscribers: lldb-commits llvm-svn: 290117
* Use Timeout<> in EvaluateExpressionOptions classPavel Labath2016-12-061-2/+2
| | | | llvm-svn: 288797
* [lldb] Fix typos in file headersAlexander Shaposhnikov2016-11-262-3/+2
| | | | | | | | | | | | | This diff fixes typos in file headers (incorrect file names). Test plan: Under llvm/tools/lldb/source: find ./* -type f | grep -e '\(cpp\|h\)$' | while read F; do B=$(basename $F); echo $F head -n 1 $F | grep -v $B | wc -l ; done Differential revision: https://reviews.llvm.org/D27115 llvm-svn: 287966
* [CMake] NFC. Updating CMake dependency specificationsChris Bieneman2016-11-181-4/+7
| | | | | | This patch updates a bunch of places where add_dependencies was being explicitly called to add dependencies on intrinsics_gen to instead use the DEPENDS named parameter. This cleanup is needed for a patch I'm working on to add a dependency debugging mode to the build system. llvm-svn: 287408
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-163-7/+7
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Make DiagnosticsManager functions take StringRefs.Zachary Turner2016-11-123-19/+18
| | | | llvm-svn: 286730
* Convert some Expression parser functions to StringRef.Zachary Turner2016-11-082-19/+16
| | | | llvm-svn: 286208
* UserExpression::Evaluate only returns a non-empty ValueObjectSPJim Ingham2016-11-071-0/+1
| | | | | | | | | | | | if it returns eExpressionCompleted. Don't try to get the error from the ValueObjectSP if that's not true. I just have a report of this from the field, I don't know how to make it fail yet. <rdar://problem/29113004> llvm-svn: 286170
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-022-2/+2
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* Use the right dwarf attributes for parsing location list entries (fixup for ↵Pavel Labath2016-10-311-2/+2
| | | | | | | | | | | | | r285441) Note that the parsing code here is still incorrect wrt. the new draft of the dwarf 5 spec (seconds arguments to DW_LLE_startx_length should be uleb128, not u32). Once we have compilers actually emitting dwarf conformant with the new spec, we'll need to revisit this and figure out the proper behavior there. This should unbreak the linux bot. llvm-svn: 285562
* Rename DWARF 5 constants to adapt to change in LLVMAdrian Prantl2016-10-281-3/+3
| | | | llvm-svn: 285441
* Remove a stray dump().Sean Callanan2016-10-071-2/+0
| | | | | | <rdar://problem/28635530> llvm-svn: 283604
* Convert some more aliasing and CI functions to StringRef.Zachary Turner2016-10-051-1/+1
| | | | llvm-svn: 283386
* [CMake] LLDB/Expression needs to depend on intrinsics_genChris Bieneman2016-09-291-0/+4
| | | | | | | | IRExecutionUnit.h includes Module.h, which through a long chain of includes eventually includes Attributes.gen. This fixes a build issue reported to lldb-dev by Hal. Thanks Hal! llvm-svn: 282803
* Added a setting that enables saving all .o files from a given JIT expression.Sean Callanan2016-09-261-0/+27
| | | | | | | | This allows debugging of the JIT and other analyses of the internals of the expression parser. I've also added a testcase that verifies that the setting works correctly when off and on. llvm-svn: 282434
* Update the prompt related functions to use StringRefs.Zachary Turner2016-09-231-5/+5
| | | | llvm-svn: 282269
* Replaced two instances of std::function with auto.Sean Callanan2016-09-141-4/+3
| | | | | | | | Thanks to Zachary Turner for the suggestion. It's distasteful that the actual type of the lambda can't be spelled out, but it should be evident from the definition of the lambda body. llvm-svn: 281536
* Cleaned up some of the "frame diagnose" code to use Operands as currency.Sean Callanan2016-09-131-62/+56
| | | | | | | Also added some utility functions around Operands to make code easier and more compact to write. llvm-svn: 281398
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0615-10454/+9728
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-061-0/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* [lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying JIT for LLDBLang Hames2016-08-191-1/+2
| | | | | | | | | | expression evaluation. OrcMCJITReplacement is a reimplementation of MCJIT using ORC components, and provides an easy upgrade path to ORC for existing MCJIT clients. There should be no functional changes resulting from this switch. llvm-svn: 279327
* Fixed a problem where we failed to get the size of an Objective-C type.Sean Callanan2016-08-181-1/+3
| | | | | | <rdar://problem/27897056> llvm-svn: 279098
* Decoupled Options from CommandInterpreter.Todd Fiala2016-08-111-4/+4
| | | | | | | | | | | | | | | | Options used to store a reference to the CommandInterpreter instance in the base Options class. This made it impossible to parse options independent of a CommandInterpreter. This change removes the reference from the base class. Instead, it modifies the options-parsing-related methods to take an ExecutionContext pointer, which the options may inspect if they need to do so. Closes https://reviews.llvm.org/D23416 Reviewers: clayborg, jingham llvm-svn: 278440
* Add an "experimental" setting to disable injecting local variables into ↵Jim Ingham2016-07-071-3/+7
| | | | | | | | | | | | | | | | expressions. This feature was added to solve a lookup problem in expressions when local variables shadow ivars. That solution requires fully realizing all local variables to evaluate any expression, and can cause significant performance problems when evaluating expressions in frames that have many complex locals. Until we get a better solution, this setting mitigates the problem when you don't have local variables that shadow ivars. <rdar://problem/27226122> llvm-svn: 274783
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-011-6/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* Fixed a problem in IRMemoryMap where the flag to zero out memory was ignored.Sean Callanan2016-06-091-0/+7
| | | | llvm-svn: 272320
* Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe.Sean Callanan2016-06-091-8/+109
| | | | | | | | | | | | | | | | | | | | | | | Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
* Now that there are no cycles that cause leaks in the ↵Greg Clayton2016-06-071-4/+0
| | | | | | | | disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue. <rdar://problem/26684190> llvm-svn: 272071
* Fix function name lookup in IRExecutionEngine.cpp.Stephane Sezer2016-06-061-1/+1
| | | | | | | | | | | | | | Summary: Without this commit, when `log enable lldb expr` is enabled, the disassembly of JIT'ed code is never displayed. Reviewers: spyffe, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20312 llvm-svn: 271863
* Fixed a problem where we couldn't call extern "C" functions.Sean Callanan2016-06-021-1/+39
| | | | | | | | | | | | | Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB has to fall back (if it is about to give up finding a symbol) to using the base name of the function. This fix also ensures that we search by full name rather than "auto," which could cause unrelated C++ names to be found. Finally, it adds a test case. <rdar://problem/25094302> llvm-svn: 271551
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-2/+2
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* [LLDB] Added support for PHI nodes to IR interpreterMarianne Mailhot-Sarrasin2016-05-121-1/+46
| | | | | | | | | | This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms). Patch by cameron314 Differential Revision: http://reviews.llvm.org/D19124 llvm-svn: 269340
* XFail TestLambdas.py on Windows after fixing some of the problemsAdrian McCarthy2016-05-041-3/+11
| | | | | | | | | | | | | | 1. Fixed semicolon placement in the lambda in the test itself. 2. Fixed lldbinline tests in general so that we don't attempt tests on platforms that don't use the given type of debug info. (For example, no DWO tests on Windows.) This fixes one of the two failures on Windows. (TestLambdas.py was the only inline test that wasn't XFailed or skipped on Windows.) 3. Set the error string in IRInterpreter::CanInterpret so that the caller doesn't print (null) instead of an explanation. I don't entirely understand the error, so feel free to suggest a better wording. 4. XFailed the test on Windows. The interpreter won't evaluate the lambda because the module has multiple function bodies. I don't exactly understand why that's a problem for the interpreter nor why the problem arises only on Windows. Differential Revision: http://reviews.llvm.org/D19606 llvm-svn: 268573
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-292-4/+2
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 268083
* Used llvm_unreached to quite a VC++ compiler warning.Adrian McCarthy2016-04-281-0/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D19489 llvm-svn: 267931
* Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath2016-04-282-2/+4
| | | | | | | | | | $__lldb_expr." This reverts commit r267833 as it breaks the build. It looks like some work in progress got committed together with the actual fix, but I'm not sure which one is which, so I'll revert the whole patch and let author resumbit it after fixing the build error. llvm-svn: 267861
* Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-282-4/+2
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 267833
* UtilityFunction::MakeFunctionCaller uses the Error to report failure,Jim Ingham2016-04-261-0/+3
| | | | | | | | but when there's was no process it was just returning an null pointer and not setting the error. I don't have a scenario where this might go wrong, just code inspection... llvm-svn: 267594
* When building the list of variables we're going to write "using ↵Jim Ingham2016-04-261-1/+1
| | | | | | | | | $_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-151-15/+26
| | | | | | | | | | | | | Recommit modified version of r266311 including build bot regression fix. This differs from the original r266311 by: - Fixing Scalar::Promote to correctly zero- or sign-extend value depending on signedness of the *source* type, not the target type. - Omitting a few stand-alone fixes that were already committed separately. llvm-svn: 266422
OpenPOWER on IntegriCloud