summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/ClangUserExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Don't allow the expression parser to magicallySean Callanan2014-10-201-1/+0
| | | | | | | | | look through 'self' at its ivars. It produces surprising results. <rdar://problem/18698760> llvm-svn: 220220
* Fixed the expression parser to handle cases whereSean Callanan2014-10-171-1/+1
| | | | | | | | | GetValueForVariableExpressionPath returns NULL and doesn't set an error. <rdar://problem/18682916> llvm-svn: 220070
* Only call RemovePersistentVariable on expr_result if that sharedJason Molenda2014-10-161-1/+1
| | | | | | pointer contains something. llvm-svn: 219966
* Another logical-or vrs. bitwise-or mixup in ClangUserExpression.Jason Molenda2014-10-161-4/+4
| | | | | | clang unreachable code warning. llvm-svn: 219918
* Check that process is non-null before calling a method in it.Jason Molenda2014-10-161-1/+1
| | | | | | clang static analyzer fixit. llvm-svn: 219886
* Reverse out r219169 related to quote handling.Todd Fiala2014-10-101-3/+1
| | | | | | | | | Addresses pr/21190 (http://llvm.org/bugs/show_bug.cgi?id=21190). r219169 implemented this change list: http://reviews.llvm.org/D5472 for more details. llvm-svn: 219461
* Add "target.expr-parser-compiler-args" setting.Todd Fiala2014-10-061-1/+3
| | | | | | | | | | | | | This setting contains the following: A list containing all the arguments to be passed to the expression parser compiler. This change also ensures quoted arguments are handled appropriately. See http://reviews.llvm.org/D5472 for more details. Change by Tong Shen. llvm-svn: 219169
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-7/+7
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Move some Host logic into HostInfo class.Zachary Turner2014-08-191-2/+2
| | | | | | | | | | | | | | | | | | This patch creates a HostInfo class, a static class used to answer basic queries about the host platform. As part of this change, some functionality is moved from Host to HostInfo, and relevant fixups are performed in the rest of the codebase. This is part of a larger effort to isolate more code in the Host layer into platform-specific groups, to make it easier to make platform specific changes for a particular Host without breaking other hosts. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4963 llvm-svn: 215992
* Add the ability to suppress the creation of a persistentJim Ingham2014-07-191-0/+5
| | | | | | | | result variable and use in in "Process::LoadImage" so that, for instance, "process load" doesn't increment the return variable number. llvm-svn: 213440
* If a hand-called function is interrupted by hitting a breakpoint, then Jim Ingham2014-07-081-7/+13
| | | | | | | when you continue to finish off the function call, the expression result will be included as part of the thread stop info. llvm-svn: 212506
* remove trailing whitespace + remove some useless commentsSylvestre Ledru2014-07-061-174/+172
| | | | llvm-svn: 212411
* Rename eExecution*** to eExpression*** to be consistent with the result type.Jim Ingham2014-05-051-23/+23
| | | | llvm-svn: 207945
* Make the Expression Execution result enum available to the SB API layer.Jim Ingham2014-05-051-27/+50
| | | | | | | | | Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
* lldb arm64 import.Jason Molenda2014-03-291-1/+1
| | | | | | | | | | | | | | | | These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
* JITed functions can now have debug info and be debugged with debug and ↵Greg Clayton2014-03-241-10/+61
| | | | | | | | | | | | | | | | | | | source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
* cleanup unreferenced functionsSaleem Abdulrasool2014-03-201-14/+14
| | | | | | | | | | | | | This is a mechanical cleanup of unused functions. In the case where the functions are referenced (in comment form), I've simply commented out the functions. A second pass to clean that up is warranted. The functions which are otherwise unused have been removed. Some of these were introduced in the initial commit and not in use prior to that point! NFC llvm-svn: 204310
* 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
OpenPOWER on IntegriCloud