summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/Materializer.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Added symbol materialization support to the newSean Callanan2013-04-131-0/+31
| | | | | | Materializer. llvm-svn: 179445
* Now that ValueObjects permit writing, made theSean Callanan2013-04-131-1/+23
| | | | | | | Materializer use that API when dematerializing variables. llvm-svn: 179443
* Implemented materialization and dematerializationSean Callanan2013-04-121-3/+156
| | | | | | | | | | | | | | for variables in the new Materializer. This is much easier now that the ValueObject API is solid. I still have to implement reading bytes into a ValueObject, but committing what I have so far. This code is not yet used, so there will be fixes when I switch the expression parser over to use the new Materializer. llvm-svn: 179416
* Replicated the materialization logic for persistentSean Callanan2013-04-121-12/+242
| | | | | | | | variables in the Materializer. We don't use this code yet, but will soon once the other materializers are online. llvm-svn: 179390
* Hand over the job of laying out the argument structureSean Callanan2013-04-111-12/+4
| | | | | | | | | | to the Materializer. Materialization is still done by the ClangExpressionDeclMap; this will be the next thing to move. Also fixed a layout bug that this uncovered. llvm-svn: 179318
* Added a Materializer class that containsSean Callanan2013-04-111-0/+275
information about each variable that needs to be materialized for an expression to work. The next step is to migrate all materialization code from ClangExpressionDeclMap to Materializer, and to use it for variable materialization. llvm-svn: 179245
OpenPOWER on IntegriCloud