summaryrefslogtreecommitdiffstats
path: root/lldb/source/Commands/CommandObjectExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLDB] Added support for PHI nodes to IR interpreterMarianne Mailhot-Sarrasin2016-05-121-1/+18
| | | | | | | | | | 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
* Fixed multiline expressions, and removed some dead code.Sean Callanan2016-05-091-18/+11
| | | | | | | | IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be implemented but isn't. This means that multiline expressions don't work. This patch fixes that. Test case to follow in the next commit. llvm-svn: 268970
* Add a --element-count option to the expression commandEnrico Granata2016-04-251-0/+23
| | | | | | | | | | | | | This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements This has a couple subtle points but is mostly as straightforward as it sounds Add a parray N <expr> alias for this new mode Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode Add a poarray N <expr> alias for this llvm-svn: 267372
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-291-1/+28
| | | | | | | | | | | | | setting to quietly apply fixits for those who really trust clang's fixits. Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present. <rdar://problem/25351938> llvm-svn: 264793
* Expose top-level Clang expressions via the command line and the API.Sean Callanan2016-03-281-0/+9
| | | | | | | | | | | | | | | | | | Top-level Clang expressions are expressions that act as new translation units, and define their own symbols. They do not have function wrappers like regular expressions do, and declarations are persistent regardless of use of the dollar sign in identifiers. Names defined by these are given priority over all other symbol lookups. This patch adds a new expression option, '-p' or '--top-level,' which controls whether the expression is treated this way. It also adds a flag controlling this to SBExpressionOptions so that this API is usable externally. It also adds a test that validates that this works. (The test requires a fix to the Clang AST importer which I will be committing shortly.) <rdar://problem/22864976> llvm-svn: 264662
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-251-0/+21
| | | | | | | | | | | | | | | "." for "->".) This feature is controlled by an expression command option, a target property and the SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions, those you have to get right when you make them. This is just a first stage. At present the fixits are applied silently. The next step is to tell the user about the applied fixit. <rdar://problem/25351938> llvm-svn: 264379
* Fix Clang-tidy modernize-use-nullptr and modernize-use-default warnings in ↵Eugene Zelenko2016-02-191-52/+39
| | | | | | some files in source/Commands; other minor fixes. llvm-svn: 261356
* Added support to the expression command for dropping into the REPL at will.Sean Callanan2015-10-201-1/+66
| | | | | | | | "expr -r" does this. It also returns to a REPL if the LLDB command interpreter is neseted inside it, for example in cases where a REPL command resulted in a breakpoint being hit or a crash. llvm-svn: 250780
* Decide on the expression language inside UserExpressionDawn Perchik2015-10-071-10/+1
| | | | | | | | | | | | | | When the target settings are consulted to decide the expression language is decided in CommandObjectExpression, this doesn't help if you're running SBFrame::EvaluateExpression(). Moving the logic into UserExpression fixes this. Based on patch from scallanan@apple.com Reviewed by: dawn Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13267 llvm-svn: 249624
* Fix minor typos in comments.Bruce Mitchener2015-10-071-1/+1
| | | | llvm-svn: 249533
* Route the preferred-display-language mechanism to the ValueObjectPrinter and ↵Enrico Granata2015-10-071-0/+1
| | | | | | actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways llvm-svn: 249507
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-151-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
* Set the default language to use when evaluating to that of the frame's CU.Dawn Perchik2015-09-041-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | * Use the frame's context (instead of just the target's) when evaluating, so that the language of the frame's CU can be used to select the compiler and/or compiler options to use when parsing the expression. This allows for modules built with mixed languages to be parsed in the context of their frame. * Add all C and C++ language variants when determining the language options to set. * Enable C++ language options when language is C or ObjC as a workaround since the expression parser uses features of C++ to capture values. * Enable ObjC language options when language is C++ as a workaround for ObjC requirements. * Disable C++11 language options when language is C++03. * Add test TestMixedLanguages.py to check that the language being used for evaluation is that of the frame. * Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has to be enabled for C, and remove redundant expr --language test for ObjC. * Fix TestPersistentPtrUpdate.py to not require C++11 in C. Reviewed by: clayborg, spyffe, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11102 llvm-svn: 246829
* Purge a few places where *LanguageRuntime.h was being used when it Jim Ingham2015-09-031-1/+0
| | | | | | wasn't needed. llvm-svn: 246744
* 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
* Move things from the LanguageRuntime that obviously belong in the new ↵Jim Ingham2015-09-021-1/+2
| | | | | | Language plugin instead. llvm-svn: 246611
* Specify a language to use when parsing expressions.Dawn Perchik2015-07-251-7/+14
| | | | | | | | | | | | This patch adds the option -l/--language to the expression command, for use when setting the language options or choosing an alternate FE. If not specified, the target.language setting is used. Reviewed by: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11447 llvm-svn: 243187
* Fixed line wrapping for the "long help" content in LLDB commands. Content ↵Kate Stone2015-07-141-29/+33
| | | | | | | | | | is now dynamically wrapped for the column width of the current terminal. Lines that begin with whitespace will be indented identically on subsequent lines to maintain formatting. Existing commands supplying this type of help content have been reworked to take advantage of the changes. In addition to formatting changes, content was changes for accuracy and clarity purposes. <rdar://problem/21269977> llvm-svn: 242122
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Add support for custom commands to set flags on themselvesEnrico Granata2015-05-271-1/+1
| | | | | | | | | This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
* Fix handling of backslashes in Args parsingPavel Labath2015-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Presently Args::SetCommandString allows quotes to be escaped with backslash. However, the backslash itself is not removed from the argument, nor there is a way to escape the backslash itself. This leads to surprising results: "a b" c" -> 'a b', 'c' # Here we actually have an unterminated quote, but that is ignored "a b\" c" -> 'a b\" c' # We try to escape the quote. That works but the backslash is not removed. "a b\\" c" -> 'a b\\" c' # Escaping the backslash has no effect. This change changes quote handling to be more shell-like: - single quotes and backquotes are literal and there is no way to escape the closing quote or anything else inside; - inside double quotes you can use backslash to escape the closing quote and another backslash - outside any quotes, you can use backslash to escape quotes, spaces and itself. This makes the parsing more consistent with what the user is familiar and increases the probability that pasting the command line from shell to the "process launch" command "just work". Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7855 llvm-svn: 230955
* Moved Args::StringToXIntYZ to StringConvert::ToXIntYZVince Harron2015-01-151-2/+2
| | | | | | | | | | The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
* This is the first step of making lldb able to create target-specific thingsJim Ingham2014-11-221-1/+1
| | | | | | | | | | | | | (e.g. breakpoints, stop-hooks) before we have any targets - for instance in your ~/.lldbinit file. These will then get copied over to any new targets that get created. So far, you can only make stop-hooks. Breakpoints will have to learn to move themselves from target to target for us to get them from no-target to new-target. We should also make a command & SB API way to prime this ur-target. llvm-svn: 222600
* Complete rewrite of interactive editing support for single- and multi-line ↵Kate Stone2014-11-171-0/+4
| | | | | | | | | | | | | | | | | | | input. Improvements include: * Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only * Fallback for ASCII editing path * Support for a "faint" prompt clearly distinguished from input * Breaking lines and insert new lines in the middle of a batch by simply pressing return * Joining lines with forward and backward character deletion * Detection of paste to suppress automatic formatting and statement completion tests * Correctly reformatting when lines grow or shrink to occupy different numbers of rows * Saving multi-line history, and correctly preserving the "tip" of history during editing * Displaying visible ^C and ^D indications when interrupting input or sending EOF * Fledgling VI support for multi-line editing * General correctness and reliability improvements llvm-svn: 222163
* Revert "Fix broken tests due to new error output."Zachary Turner2014-07-091-6/+6
| | | | | | | This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
* Document the "thread.completed-expression" feature in the "expression" ↵Jim Ingham2014-07-081-0/+9
| | | | | | command help. llvm-svn: 212558
* Fix broken tests due to new error output.Todd Fiala2014-07-081-6/+6
| | | | | | | | | | | This reverses out the options validators changes. We'll get these back in once the changes to the output can be resolved. Restores broken tests on FreeBSD, Linux, MacOSX. Changes reverted: r212500, r212317, r212290. llvm-svn: 212543
* Adds the notion of an OptionValidator.Zachary Turner2014-07-031-6/+6
| | | | | | | | | | | | | | | | | | The purpose of the OptionValidator is to determine, based on some arbitrary set of conditions, whether or not a command option is valid for a given debugger state. An example of this might be to selectively disable or enable certain command options that don't apply to a particular platform. This patch contains no functional change, and does not actually make use of an OptionValidator for any purpose yet. A follow-up patch will begin to add the logic and users of OptionValidator. Reviewed by: Greg Clayton, Jim Ingham Differential Revision: http://reviews.llvm.org/D4369 llvm-svn: 212290
* Fix typos.Bruce Mitchener2014-07-011-1/+1
| | | | llvm-svn: 212132
* lldb: remove adhoc implementation of array_sizeofSaleem Abdulrasool2014-06-271-1/+2
| | | | | | | | Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
* A fix for: http://llvm.org/bugs/show_bug.cgi?id=19241 Greg Clayton2014-03-251-1/+1
| | | | | | When there was no process, the expression options were set to not ignore breakpoints. This causes debug info to be generated and causes errors when evaluating simple expressions. llvm-svn: 204745
* JITed functions can now have debug info and be debugged with debug and ↵Greg Clayton2014-03-241-0/+6
| | | | | | | | | | | | | | | | | | | 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 some dead assignements reported by scan-buildArnaud A. de Grandmaison2014-03-221-7/+3
| | | | | | No functionnal change. llvm-svn: 204545
* One more time. Multi-line expressions when there is no valid expression that ↵Greg Clayton2014-03-131-1/+1
| | | | | | follow “expr [options] —“. llvm-svn: 203874
* Fixed crasher when “expr” was NULL due to no characters following the ↵Greg Clayton2014-03-131-1/+1
| | | | | | terminating "--". llvm-svn: 203873
* Allow a multi-line expression to follow expression commands with options ↵Greg Clayton2014-03-131-19/+32
| | | | | | when there is no expression following the option terminating “—“. llvm-svn: 203872
* Allow line numbers to be shown in multi-line expressions.Greg Clayton2014-03-071-0/+1
| | | | llvm-svn: 203185
* When a multiline expression produces output, the multi-line help message is ↵Greg Clayton2014-02-111-12/+7
| | | | | | | | printed twice. <rdar://problem/16031890> llvm-svn: 201171
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-107/+63
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* The default timeout for EvaluateExpressionOptions is not 0, so if no timeout ↵Jim Ingham2014-01-171-0/+2
| | | | | | | | is provided, we have to set the option timeout to 0 by hand. <rdar://problem/15846781> llvm-svn: 199509
* This patch does a couple of things. Jim Ingham2013-11-071-7/+7
| | | | | | | | | | | | | | | | | | | | | | 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-2/+13
| | | | | | | | 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-1/+1
| | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/14393032>Enrico Granata2013-09-301-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
* Add OptionParser.hVirgile Bello2013-09-051-4/+4
| | | | llvm-svn: 190063
* Send a stop event when an expression stops at a breakpointSean Callanan2013-07-301-30/+1
| | | | | | | | | | in an expression and doesn't ignore the stop. Patch by Jim Ingham. <rdar://problem/14583884> llvm-svn: 187434
* For "expr", say what the timeout units are in the help string.Jim Ingham2013-05-291-1/+1
| | | | llvm-svn: 182873
* Fix the help for unwind-on-error, it no longer controls what happens when an ↵Jim Ingham2013-04-091-1/+1
| | | | | | expression hits a breakpoint. llvm-svn: 179133
OpenPOWER on IntegriCloud