summaryrefslogtreecommitdiffstats
path: root/lldb/source/Commands/CommandObjectCommands.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Make sure the "command regex add" has a unique name for editline history ↵Greg Clayton2014-07-091-1/+1
| | | | | | purposes. llvm-svn: 212644
* Revert "Fix broken tests due to new error output."Zachary Turner2014-07-091-17/+17
| | | | | | | This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and re-enables OptionValidators. llvm-svn: 212627
* Fix broken tests due to new error output.Todd Fiala2014-07-081-17/+17
| | | | | | | | | | | 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-17/+17
| | | | | | | | | | | | | | | | | | 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 TOT is dropping the last entry for multi-line IOHandlers that use the ↵Greg Clayton2014-05-081-1/+1
| | | | | | | | IOHandlerDelegateMultiline. <rdar://problem/16844164> llvm-svn: 208336
* "DONE" is being left in multi-line results when it shouldn't for non ↵Greg Clayton2014-05-021-1/+1
| | | | | | | | terminal input. <rdar://problem/16790579> llvm-svn: 207818
* Allow line numbers to be shown in multi-line expressions.Greg Clayton2014-03-071-2/+3
| | | | llvm-svn: 203185
* Fixed output to display correctly for "command source" by fixing the correct ↵Greg Clayton2014-02-051-2/+0
| | | | | | | | | | flags being set. Also emit the "Executing commands" message so it properly only comes out when desired and so it comes out in the right place. <rdar://problem/15992208> llvm-svn: 200875
* Fixed an issue where "command source" would not do the right thing:Greg Clayton2014-02-051-26/+45
| | | | | | | - empty lines in init files would repeat previous command and cause errors to be displayed - all options to control showing the command, its output, if it should stop on error or continue, weren't being obeyed. llvm-svn: 200860
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-250/+200
| | | | | | | | | | | | 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
* Add OptionParser.hVirgile Bello2013-09-051-12/+12
| | | | llvm-svn: 190063
* Remove need of <functional> for CommandObjectCommands.Virgile Bello2013-08-271-3/+3
| | | | llvm-svn: 189365
* Add silent option to command source.Michael Sartain2013-07-091-1/+9
| | | | | | Patch from Matthew Sorrels llvm-svn: 185983
* Revert commits that cause broken builds on GCC buildbotsDaniel Malea2013-07-031-3/+1
| | | | | | | | - build fails due to PyCallable template definition inside an extern "C" scope This commit reverts 185240, 184893 and 184608. llvm-svn: 185560
* <rdar://problem/14266578>Enrico Granata2013-06-261-3/+1
| | | | | | "command source" was not properly setting the stop-on-error option llvm-svn: 184899
* <rdar://problem/14266411>Enrico Granata2013-06-251-1/+3
| | | | | | | | | | | | The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened This checkin changes that: - SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string - script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior llvm-svn: 184893
* Renaming the "--wipe" option to "command history" to "--clear" (-C) for ↵Enrico Granata2013-06-171-8/+8
| | | | | | coherence with the rest of the LLDB command-line interface llvm-svn: 184147
* <rdar://problem/14134716>Enrico Granata2013-06-171-24/+106
| | | | | | | | | | | | This is a rewrite of the command history facility of LLDB It takes the history management out of the CommandInterpreter into its own CommandHistory class It reimplements the command history command to allow more combinations of options to work correctly (e.g. com hist -c 1 -s 5) It adds a new --wipe (-w) option to command history to allow clearing the history on demand It extends the lldbtest runCmd: and expect: methods to allow adding commands to history if need be It adds a test case for the reimplemented facility llvm-svn: 184140
* <rdar://problem/12876503>Enrico Granata2013-06-111-6/+9
| | | | | | | Adding a new setting interpreter.stop-command-source-on-error that dictates a default behavior for whether command source should stop upon hitting an error You can still override the setting for each individual invocation with the usual -e setting llvm-svn: 183719
* <rdar://problem/11109316>Enrico Granata2013-05-311-2/+2
| | | | | | | | | | | | | | | | | command script import now does reloads - for real If you invoke command script import foo and it detects that foo has already been imported, it will - invoke reload(foo) to reload the module in Python - re-invoke foo.__lldb_init_module This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing Usual caveats with Python imports persist. Among these: - if you have objects lurking around, reloading the module won't magically update them to reflect changes - if module A imports module B, reloading A won't reload B These are Python-specific issues independent of LLDB that would require more extensive design work The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not llvm-svn: 182977
* <rdar://problem/13831149>Enrico Granata2013-05-091-0/+7
| | | | | | | | Recursive commands invocations are not currently supported by our CommandInterpreter CommandScriptImport can actually be made to invoke itself recursively, so we need to work around that by clearing the m_exe_ctx This is a short-term workaround, a more interesting solution would be to actually make sure recursive command invocations work properly llvm-svn: 181537
* 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
* 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
* <rdar://problem/13069948>Greg Clayton2013-01-251-3/+3
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* <rdar://problem/12798131> Greg Clayton2012-12-041-5/+5
| | | | | | | | | | | | Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite. This fix does the following: - make sure all short options are treated as "int" - make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired - fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates - fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value llvm-svn: 169189
* <rdar://problem/12491420>Greg Clayton2012-10-181-0/+2
| | | | | | | | | | Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
* <rdar://problem/12491387>Greg Clayton2012-10-131-2/+1
| | | | | | | | | | | I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override: virtual CommandObject * GetPluginCommandObject(); This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented! llvm-svn: 165861
* Added a new "module" log channel which covers module creation, deletion, and ↵Greg Clayton2012-10-081-1/+1
| | | | | | | | | | common module list actions. Also added a new option for "log enable" which is "--stack" which will print out a stack backtrace for each log line. This was used to track down the leaking module issue I fixed last week. llvm-svn: 165438
* <rdar://problem/12188843> Fixing a problem where a Python command created in ↵Enrico Granata2012-09-181-8/+20
| | | | | | the same module where the target function is defined causes the help string not to come out llvm-svn: 164172
* Fixed some small formatting issues in the help forSean Callanan2012-08-161-2/+4
| | | | | | | | | "command regex." It's now more readable and grammatically correct. <rdar://problem/12115962> llvm-svn: 162047
* <rdar://problem/11975483> Removing user-visible references to 'dict' as a ↵Enrico Granata2012-08-081-1/+1
| | | | | | parameter name for Python summary-generating functions since it is a Python keyword. llvm-svn: 161467
* Make a way to set the result status for Python defined commands, and don't ↵Jim Ingham2012-06-271-1/+12
| | | | | | | | overwrite the status of the result if the python command has set it. llvm-svn: 159273
* Make raw & parsed commands subclasses of CommandObject rather than having ↵Jim Ingham2012-06-081-402/+343
| | | | | | | | | | | | | | | | the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
* <rdar://problem/11328896> Fixing a bug where regex commands were saved in ↵Enrico Granata2012-05-311-1/+32
| | | | | | the history even if they came from a 'command sourced' file - this fix introduces a command sourcing depth and disables history for all levels of depth > 0, which means no commands go into history when being sourced from a file. we need an integer depth because command files might themselves source other command files, ... llvm-svn: 157727
* Using the new ScriptInterpreterObject in the implementation of synthetic ↵Enrico Granata2012-03-061-12/+4
| | | | | | | | | children to enhance type safety Several places in the ScriptInterpreter interface used StringList objects where an std::string would suffice - Fixed Refactoring calls that generated special-purposes functions in the Python interpreter to use helper functions instead of duplicating blobs of code llvm-svn: 152164
* Fix help strings that refer to the "commands" top-level noun. Jason Molenda2011-11-101-9/+9
| | | | | | It's "command", "commands" is not recognized. llvm-svn: 144327
* this patch addresses several issues with "command script" subcommands:Enrico Granata2011-11-071-20/+159
| | | | | | | | | | | | a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled) b) clears up several error messages c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before d) allows filename completion for "command script import" (much like what happens for "target create") e) prevents "command script add" from replacing built-in commands with scripted commands f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons) plus, it fixes an issue in "type summary add" command handling which caused several test suite errors llvm-svn: 144035
* Cleaned up many error codes. For any who is filling in error strings intoGreg Clayton2011-10-261-10/+10
| | | | | | | | | | | | | lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
* this patch introduces a new command script import command which takes as ↵Enrico Granata2011-10-171-0/+73
| | | | | | input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
* Redesign of the interaction between Python and frozen objects:Enrico Granata2011-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
* Fix the "command alias" help string to make clear that the $<N> ↵Jim Ingham2011-08-181-2/+10
| | | | | | substitutions should be whole words in the output command. llvm-svn: 137921
* When defining a scripted command, it is possible to provide a docstring and ↵Enrico Granata2011-08-171-0/+17
| | | | | | | | | | that will be used as the help text for the command If no docstring is provided, a default help text is created LLDB will refuse to create scripted commands if the scripting language is anything but Python Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code llvm-svn: 137801
* Changes to Python commands:Enrico Granata2011-08-161-210/+531
| | | | | | | | | | | | - They now have an SBCommandReturnObject instead of an SBStream as third argument - The class CommandObjectPythonFunction has been merged into CommandObjectCommands.cpp - The command to manage them is now: command script with subcommands add, list, delete, clear command alias is returned to its previous functionality - Python commands are now part of an user dictionary, instead of being seen as aliases llvm-svn: 137785
* Python commands:Enrico Granata2011-08-161-0/+218
| | | | | | | | | | | | | It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function (e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl') The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where debugger is an object wrapping an LLDB SBDebugger args is the command line arguments, as an unparsed Python string stream is an SBStream that represents the standard output dict is an internal utility parameter and should be left untouched The function should return None on no error, or an error string to describe any problems llvm-svn: 137722
* Added "command history" command to dump the command history.Jim Ingham2011-07-121-0/+127
| | | | | | | | | | | | | | | | | Also made: (lldb) !<NUM> (lldb) !-<NUM> (lldb) !! work with the history. For added benefit: (lldb) !<NUM><TAB> will insert the command at position <NUM> in the history into the command line to be edited. This is only partial, I still need to sync up editline's history list with the one kept by the interpreter. llvm-svn: 134955
* Add 'batch_mode' to CommandInterpreter. Modify InputReaders toCaroline Tice2011-06-161-6/+14
| | | | | | | | | | not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
* Replace direct uses of the Debugger's output stream withCaroline Tice2011-06-151-5/+15
| | | | | | uses of the asynchronous stream. llvm-svn: 133076
* Replace calls to HandleCommand in lldb core with more appropriateCaroline Tice2011-05-061-58/+19
| | | | | | | direct function calls. As part of this, collect code that processes arguments & options for aliases into a single function. llvm-svn: 131020
OpenPOWER on IntegriCloud