summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/ClangUserExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Only require thread scope when we're about to run the function on a thread.Jim Ingham2014-03-031-6/+6
| | | | llvm-svn: 202740
* Don't require a valid thread if expr can be evaluated staticallyEd Maste2014-03-031-1/+1
| | | | | | | This seems reasonable and the BackticksWithNoTargetTestCase suggests it should be this way. llvm-svn: 202722
* Make sure the exe_ctx passed to ClangUserExpression::Execute has a valid thread.Jim Ingham2014-03-011-0/+6
| | | | | | <rdar://problem/15949113> llvm-svn: 202561
* Better error reporting when a variable can't beSean Callanan2014-02-281-1/+1
| | | | | | | | | | | 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
* Fix the test suite after the changes made in revision 196616 exposed issues ↵Greg Clayton2013-12-101-1/+3
| | | | | | | | in the test suite. We must make sure that all ValueObject objects always contain a valid target. llvm-svn: 196983
* Changed the ABIs and ClangFunction to take aSean Callanan2013-11-081-3/+12
| | | | | | | | | | | | | llvm::ArrayRef of arguments rather than taking a fixed number of possibly-NULL pointers to arguments. Also changed ClangFunction::GetThreadPlanToCallFunction to take the address of the argument struct by value instead of by reference, since it doesn't actually modify the value passed into it. llvm-svn: 194232
* This patch does a couple of things. Jim Ingham2013-11-071-61/+15
| | | | | | | | | | | | | | | | | | | | | | It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
* Added a "--debug" option to the "expression" command. Greg Clayton2013-11-041-50/+27
| | | | | | | | Cleaned up ClangUserExpression::Evaluate() to have only one variant that takes a "const EvaluateExpressionOptions& options" instead of taking many arguments. The "--debug" option is designed to allow you to debug your expression by stopping at the first instruction (it enables --ignore-breakpoints=true and --unwind-on-error=false) and allowing you to step through your JIT code. It needs to be more integrated with the thread plan, so I am checking this in so Jim Ingham can make it happen. llvm-svn: 194009
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-12/+12
| | | | | | | | | | 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-12/+12
| | | | | | | | | | | | | | | | | | | | | 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
* Fixed a leak of ASTStructExtractors and alsoSean Callanan2013-10-101-9/+3
| | | | | | | | | made sure we don't keep around no-longer-valid ASTTransformers. <rdar://problem/15182379> llvm-svn: 192333
* Make sure that ClangExpressionDeclMap doesn'tSean Callanan2013-08-231-1/+6
| | | | | | | | | | | | | | live beyont parsing. This is important because all the ClangASTImporter::Minions for a parser's ASTContext are cleared when ClangExpressionDeclMap is deleted. This resolves many hard-to-reproduce crashes, especially ones involving breakpoint conditions. <rdar://problem/14775391> llvm-svn: 189080
* Modified the expression parser to only try toSean Callanan2013-07-121-5/+2
| | | | | | | | | | | | | | | 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-7/+25
| | | | | | | | 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
* Performance optimizations to ClangUserExpression,Sean Callanan2013-04-271-22/+61
| | | | | | | | | | | | | | | | | | | | 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 some linux buildbot warnings.Greg Clayton2013-04-191-1/+1
| | | | llvm-svn: 179892
* Optimized the way breakpoint conditions are evaluated.Sean Callanan2013-04-191-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the options for a breakopint or its locations stored only the text of the breakpoint condition (ironically, they used ClangUserExpression as a glorified std::string) and, each time the condition had to be evaluated in the StopInfo code, the expression parser would be invoked via a static method to parse and then execute the expression. I made several changes here: - Each breakpoint location now has its own ClangUserExpressionSP containing a version of the breakpoint expression compiled for that exact location. - Whenever the breakpoint is hit, the breakpoint condition expression is simply re-run to determine whether to stop. - If the process changes (e.g., it's re-run) or the source code of the expression changes (we use a hash so as to avoid doing string comparisons) the ClangUserExpressionSP is re-generated. This should improve performance of breakpoint conditions significantly, and takes advantage of the recent expression re-use work. llvm-svn: 179838
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-1/+1
| | | | | | the macros and just use C++11. llvm-svn: 179805
* This commit changes the way LLDB executes userSean Callanan2013-04-181-137/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-1/+1
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* Flipped the big switch: LLDB now uses the new Sean Callanan2013-04-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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 a Materializer class that containsSean Callanan2013-04-111-1/+4
| | | | | | | | | | 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
* Factored out memory access into the target processSean Callanan2013-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from IRExecutionUnit into a superclass called IRMemoryMap. IRMemoryMap handles all reading and writing, ensuring that areas are kept track of and memory is properly cached (and deleted). Also fixed several cases where we would simply leak binary data in the target process over time. Now the expression objects explicitly own their IRExecutionUnit and delete it when they go away. This is why I had to modify ClangUserExpression, ClangUtilityFunction, and ClangFunction. As a side effect of this, I am removing the JIT mutex for an IRMemoryMap. If it turns out that we need this mutex, I'll add it in then, but right now it's just adding complexity. This is part of a more general project to make expressions fully reusable. The next step is to make materialization and dematerialization use the IRMemoryMap API rather than writing and reading directly from the process's memory. This will allow the IR interpreter to use the same data, but in the host's memory, without having to use a different set of pointers. llvm-svn: 178832
* Use the error from ValidatePlan.Jim Ingham2013-03-281-1/+1
| | | | llvm-svn: 178204
* <rdar://problem/13521159>Greg Clayton2013-03-271-6/+6
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Don't use a "uintptr_t" for the metadata key, use a "void *". This removes ↵Greg Clayton2013-03-271-1/+1
| | | | | | all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata. llvm-svn: 178113
* Refactored the expression parser so that the IRSean Callanan2013-03-191-16/+3
| | | | | | | | | | | | | | | | | | | | | | | | | and the JITted code are managed by a standalone class that handles memory management itself. I have removed RecordingMemoryManager and ProcessDataAllocator, which filled similar roles and had confusing ownership, with a common class called IRExecutionUnit. The IRExecutionUnit manages all allocations ever made for an expression and frees them when it goes away. It also contains the code generator and can vend the Module for an expression to other clases. The end goal here is to make the output of the expression parser re-usable; that is, to avoid re-parsing when re-parsing isn't necessary. I've also cleaned up some code and used weak pointers in more places. Please let me know if you see any leaks; I checked myself as well but I might have missed a case. llvm-svn: 177364
* Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction ↵Jim Ingham2013-02-091-1/+1
| | | | | | | | | | | interoperate to fix problems where hitting auto-continue signals while running a thread plan would cause us to lose control of the debug session. <rdar://problem/12993641> llvm-svn: 174793
* Add "thread return -x" to unwind the innermost user called expression (if ↵Jim Ingham2013-01-311-2/+2
| | | | | | | | | | you happen to have stopped in it due to a crash.) Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x". rdar://problem/13110464 llvm-svn: 174095
* Extended LLDB to handle blocks capturing 'self'Sean Callanan2013-01-191-2/+83
| | | | | | | | | | | | | | | in an Objective-C class method. Before, errors of the form error: cannot find interface declaration for '$__lldb_objc_class' would appear when running any expression when the current frame is a block that captures 'self' from an Objective-C class method. <rdar://problem/12905561> llvm-svn: 172880
* Separated the "expr --unwind-on-error" behavior into two parts, actual ↵Jim Ingham2013-01-151-11/+23
| | | | | | | | | | | | | | | | errors (i.e. crashes) which continue to be controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes more sense. Also make both these behaviors globally settable through "settings set". Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing and crashing. Now we just stop without calling the second command. <rdar://problem/12986644> <rdar://problem/9119325> llvm-svn: 172503
* Now that we set ThreadPlanCallFunction to private in the constructor, it is ↵Jim Ingham2012-12-071-3/+1
| | | | | | | | confusing that we set it again in client code after creating the plans. So remove those unnecessary calls. llvm-svn: 169625
* The expression parser will now check the validitySean Callanan2012-12-061-1/+1
| | | | | | | | | | | | of the "self"/"this" pointer for the current stack frame before wrapping expressions in C++ or Objective-C methods. This works around bad debug info where the compiler emits a "this" or "self" but doesn't give any way to find its location. <rdar://problem/12809985> llvm-svn: 169461
* Added logging to the code that determinesSean Callanan2012-12-011-1/+26
| | | | | | | whether the current frame is in a C++/Objective-C class or instance method. llvm-svn: 169062
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-4/+4
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Make blocks that capture their containing method's object pointer look like ↵Jim Ingham2012-10-301-0/+27
| | | | | | | | | | methods of the containing class so that direct ivar access will work in the expression parser. <rdar://problem/9797999> llvm-svn: 167061
* Add the ability to set timeout & "run all threads" options both from the ↵Jim Ingham2012-10-161-6/+20
| | | | | | | | | | "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
* Bunch of cleanups for warnings found by the llvm static analyzer.Jim Ingham2012-10-121-1/+1
| | | | llvm-svn: 165808
* Making ClangExpression hold on to a WP to the Process instead of a SP. This ↵Enrico Granata2012-09-181-1/+1
| | | | | | fix should enable us to have per-process maps of ClangExpressions without fear of keeping the process alive forever llvm-svn: 164082
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+1
| | | | | | | | | | | | Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
* Fix missing braces from the python-GIL merge.Johnny Chen2012-08-181-1/+4
| | | | llvm-svn: 162162
* Merge python-GIL bracnh (by filcab) back into trunk!Johnny Chen2012-08-181-1/+4
| | | | llvm-svn: 162161
* Removed explicit NULL checks for shared pointersSean Callanan2012-08-091-1/+1
| | | | | | | | | and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
* <rdar://problem/11672978> Fixing an issue where an ObjC object might come ↵Enrico Granata2012-07-161-7/+9
| | | | | | out without a description because the expression used to obtain it would timeout before running to completion llvm-svn: 160326
* <rdar://problem/11870357>Greg Clayton2012-07-141-22/+19
| | | | | | Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
* Be a little more safe when checking whether theSean Callanan2012-07-131-1/+1
| | | | | | | | | | | current symbol context is a C++ or Objective-C instance method. Specifically, ensure that we fetch information on the current block, not just the current function. llvm-svn: 160195
* Initialize ivars in the correct order.Bill Wendling2012-04-031-3/+3
| | | | llvm-svn: 153947
* Updated LLVM to take a new MC JIT that supportsSean Callanan2012-03-011-11/+0
| | | | | | | | | | allocations by section. We install these sections in the target process and inform the JIT of their new locations. Also removed some unused variable warnings. llvm-svn: 151789
* <rdar://problem/10103468>Greg Clayton2012-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
* Fixed a bunch of ownership problems with the expressionSean Callanan2012-02-101-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | parser. Specifically: - ClangUserExpression now keeps weak pointers to the structures it needs and then locks them when needed. This ensures that they continue to be valid without leaking memory if the ClangUserExpression is long lived. - ClangExpressionDeclMap, instead of keeping a pointer to an ExecutionContext, now contains an ExecutionContext. This prevents bugs if the pointer or its contents somehow become stale. It also no longer requires that ExecutionContexts be passed into any function except its initialization function, since it can count on the ExecutionContext still being around. There's a lot of room for improvement (specifically, ClangExpressionDeclMap should also use weak pointers insetad of shared pointers) but this is an important first step that codifies assumptions that already existed in the code. llvm-svn: 150217
OpenPOWER on IntegriCloud