summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/Materializer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Support floating point values in 128-bit SSE vector registersAdrian Prantl2016-03-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The System-V x86_64 ABI requires floating point values to be passed in 128-but SSE vector registers (xmm0, ...). When printing such a variable this currently yields an <invalid load address>. This patch makes LLDB's DWARF expression evaluator accept 128-bit registers as scalars. It also relaxes the check that the size of the result of the DWARF expression be equal to the size of the variable to a greater-than. DWARF defers to the ABI how smaller values are being placed in a larger register. Implementation note: I found the code in Value::SetContext() that changes the m_value_type after the fact to be questionable. I added a sanity check that the Value's memory buffer has indeed been written to (this is necessary, because we may have a scalar value in a vector register), but really I feel like this is the wrong place to be setting it. Reviewed by Greg Clayton. http://reviews.llvm.org/D17897 rdar://problem/24944340 llvm-svn: 262947
* Revert "Fix bug with register values byte order in expression evaluation."Todd Fiala2016-02-271-10/+3
| | | | | | | | | This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot. See details in: https://llvm.org/bugs/show_bug.cgi?id=26758 llvm-svn: 262156
* Register value is not necessarily scalar.Chaoren Lin2016-02-261-261/+262
| | | | | | | | | | Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
* Fix bug with register values byte order in expression evaluation.Aidan Dodds2016-02-261-3/+9
| | | | | | | | | | The evaluation of expressions containing register values was broken for targets for which endianness differs from host. Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com> Differential revision: http://reviews.llvm.org/D17167 llvm-svn: 262041
* Fixed a bug where the size of a type was used instead of the size of a pointer.Sean Callanan2015-11-101-1/+1
| | | | llvm-svn: 252655
* Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. ↵Jim Ingham2015-11-041-3/+18
| | | | | | | | Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
* Fix Clang-tidy modernize-use-override warnings in some files in source; ↵Eugene Zelenko2015-10-261-51/+72
| | | | | | other minor fixes. llvm-svn: 251309
* Add PersistentVariableDelegate to handle language-specific dematerialization.Sean Callanan2015-10-031-33/+42
| | | | | | | | | | | | | | | | | | | | | | | | The concept here is that languages may have different ways of communicating results. In particular, languages may have different names for their result variables and in fact may have multiple types of result variables (e.g., error results). Materializer was tied to one specific model of result handling. Instead, now UserExpressions can register their own handlers for the result variables they inject. This allows language-specific code in Materializer to be moved into the expression parser plug-in, and it simplifies Materializer. These delegates are subclasses of PersistentVariableDelegate. PersistentVariableDelegate can provide the name of the result variable, and is notified when the result variable is populated. It can also be used to touch persistent variables if need be, updating language-specific state. The UserExpression owns the delegate and can decide on its result based on consulting all of its (potentially multiple) delegates. The user expression itself now makes the determination of what the final result of the expression is, rather than relying on the Materializer, and I've added a virtual function to UserExpression to allow this. llvm-svn: 249233
* Made GetScratchTypeSystemForLanguage return an error if desired.Sean Callanan2015-10-021-2/+3
| | | | | | | Also made it not store nullptrs in its TypeSystemMap, so it will retry to make the AST context if it errored out last time. llvm-svn: 249167
* Eliminated redundant "constructors" for ClangExpressionVariable. ↵Sean Callanan2015-10-011-7/+6
| | | | | | | | | | | | | The ClangExpressionVariable::CreateVariableInList functions looked cute, but caused more confusion than they solved. I removed them, and instead made sure that there are adequate facilities for easily adding newly-constructed ExpressionVariables to lists. I also made some of the constructors that are common be generic, so that it's possible to construct expression variables from generic places (like the ABI and ValueObject) without having to know the specifics about the class. llvm-svn: 249095
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-4/+19
| | | | | | | | | | the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
* Removed a bunch of dependencies of Materializer on ClangUserExpression.Sean Callanan2015-09-291-24/+24
| | | | | | Instead we now just generically use UserExpression. llvm-svn: 248842
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-2/+2
| | | | | | | | | There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
* Removed a needless cast to ClangExpressionVariable.Sean Callanan2015-09-171-1/+1
| | | | llvm-svn: 247910
* ExpressionVariable now uses llvm::cast() instead of As...() for RTTI.Sean Callanan2015-09-081-2/+2
| | | | | | | | As part of our overall switch from hand-rolling RTTI to using LLVM-compatible methods, I've done the same for ExpressionVariable. The main documentation for how to do this is in TypeSystem.h, so I've simply referred to that. llvm-svn: 247085
* This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan2015-09-041-16/+15
| | | | | | | | | stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 llvm-svn: 246871
* Jim told me about a cleaner way to include headers from plug-ins.Sean Callanan2015-09-031-1/+1
| | | | | | | | This is still something I need to fix, but at least it's not so ugly, and it's consistent with the other code that does that so we will catch it when we purge all such code. llvm-svn: 246738
* In preparation for factoring persistent variables into a generic part and aSean Callanan2015-09-031-1/+1
| | | | | | | | | | | | Clang-specific part, create the ExpressionVariable source/header file and move ClangExpressionVariable into the Clang expression parser plugin. It is expected that there are some ugly #include paths... these will be resolved by either (1) making that code use generic expression variables (once they're separated appropriately) or (2) moving that code into a plug-in, often the expression parser plug-in. llvm-svn: 246737
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-2/+2
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* ClangASTType is now CompilerType.Greg Clayton2015-08-111-1/+1
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-1/+1
| | | | | | | | | | | | | | | 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
* Don't #include ClangPersistentVariables.h from Process.hZachary Turner2015-03-031-0/+1
| | | | | | | Nothing from this header file was even being referenced in Process.h anyway, so it was a completely unnecessary include. llvm-svn: 231131
* Preparatory infrastructural work to support dynamically determining sizes of ↵Enrico Granata2015-01-281-2/+2
| | | | | | | | | | | | ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
* Fix some typos:Sylvestre Ledru2014-08-111-1/+1
| | | | | | | | * transfered => transferred * unkown => unknown * sucessfully => successfully llvm-svn: 215367
* Fixed a flipped conditional when writing back theSean Callanan2014-04-241-1/+1
| | | | | | | | | | | | values of variables in the Materializer. The Materializer should not write the variable back if its new value is the *same* as the old value, not if the new value is *different*. <rdar://problem/16712205> llvm-svn: 207148
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-18/+20
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* Made the Materializer not write back variablesSean Callanan2014-03-251-5/+23
| | | | | | | | | | | if they didn't change, just like it does for registers. This makes life easier for kernel debugging and any other situation where values are read-only. <rdar://problem/16367795> llvm-svn: 204764
* Better error reporting when a variable can't beSean Callanan2014-02-281-3/+25
| | | | | | | | | | | read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
* Harden the Materializer logic against types thatSean Callanan2014-01-141-0/+6
| | | | | | don't know their bit alignment. llvm-svn: 199173
* Fixed a bug where the expression parser doesn'tSean Callanan2014-01-071-1/+3
| | | | | | | | | materialize a variable in a register correctly if the variable is a pointer. This fixes a regression introduced by my commit of Oct. 22nd (r193191). llvm-svn: 198718
* Fixed printf warnings. The GetByteSize() results return uint64_t values, not ↵Greg Clayton2013-11-131-1/+4
| | | | | | size_t values. llvm-svn: 194587
* Increase log detail for size mismatch in EntityVariable::MaterializeEd Maste2013-11-111-1/+1
| | | | llvm-svn: 194413
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-14/+14
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-14/+14
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Simplified the code that materializes a variable,Sean Callanan2013-10-221-9/+3
| | | | | | obviating the need to create a new ValueObject. llvm-svn: 193191
* Fixed a bug in the Materializer where we sent theSean Callanan2013-10-091-1/+1
| | | | | | | | wrong information to ValueObjectConstResult. <rdar://problem/15101795> llvm-svn: 192264
* Modified the expression parser to only try toSean Callanan2013-07-121-0/+13
| | | | | | | | | | | | | | | write to registers if they were modified in the expression. This eliminates spurious errors if the register can't be written to but the expression didn't write to it anyway. Also improved error handling for the materializer to make "couldn't materialize struct" errors more informative. <rdar://problem/14322579> llvm-svn: 186228
* Huge change to clean up types.Greg Clayton2013-07-111-68/+116
| | | | | | | | A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
* Fixed a problem with materialization andSean Callanan2013-06-201-1/+6
| | | | | | | | | | dematerialization of registers that caused conditional breakpoint expressions not to work properly. Also added a testcase. <rdar://problem/14129252> llvm-svn: 184451
* Fix various build warnings.Matt Kopec2013-06-031-15/+15
| | | | llvm-svn: 183140
* Fixed a bug where persistent variables did notSean Callanan2013-05-221-0/+4
| | | | | | | | | | | | | | | | | live as long as they needed to. This led to equality tests involving persistent variables often failing or succeeding when they had no business doing so. To do this, I introduced the ability for a memory allocation to "leak" - that is, to persist in the process beyond the lifetime of the expression. Hand-declared persistent variables do this now. <rdar://problem/13956311> llvm-svn: 182528
* <rdar://problem/13893094>Greg Clayton2013-05-171-76/+42
| | | | | | Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
* Performance optimizations to ClangUserExpression,Sean Callanan2013-04-271-2/+2
| | | | | | | | | | | | | | | | | | | | mostly related to management of the stack frame for the interpreter. - First, if the expression can be interpreted, allocate the stack frame in the target process (to make sure pointers are valid) but only read/write to the copy in the host's memory. - Second, keep the memory allocations for the stack frame and the materialized struct as member variables of ClangUserExpression. This avoids memory allocations and deallocations each time the expression runs. <rdar://problem/13043685> llvm-svn: 180664
* Fixed the expression parser's handling of resultSean Callanan2013-04-201-15/+40
| | | | | | | | | | and persistent variables so that they are not treated as remaining in the target process (i.e., having live data) when the process does not allow persistent allocations (e.g., when there is no process or in the case of kernel core files). llvm-svn: 179919
* Fixed two problems when reading constant/registerSean Callanan2013-04-191-1/+1
| | | | | | | | | | | | | | variables in the ValueObject code: - Report an error if the variable does not have a valid address. - Return the contents of the data to GetData(), even if the value is constant. <rdar://problem/13690855> llvm-svn: 179876
* This commit changes the way LLDB executes userSean Callanan2013-04-181-20/+252
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
* Flipped the big switch: LLDB now uses the new Sean Callanan2013-04-161-50/+122
| | | | | | | | | | | | | | | | | | | | | | | | Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
* Added logging to each entity in the MaterializerSean Callanan2013-04-151-1/+211
| | | | | | to make debugging easier when things go wrong. llvm-svn: 179576
* Added support for registers to the Materializer.Sean Callanan2013-04-151-0/+113
| | | | | | | Also improved logging and error handling in a few spots in the Materializer. llvm-svn: 179557
* Audited the existing Materializer code to ensureSean Callanan2013-04-151-4/+27
| | | | | | | | that it works in the absence of a process. Codepaths in the Materializer now use the best execution context scope available to them. llvm-svn: 179539
OpenPOWER on IntegriCloud