| b9d995d0863e1860c12c4ace0d5eb0ba832f9c99 |
|
09-Jul-2013 |
Enrico Granata <egranata@apple.com> |
Second attempt at getting the PyCallable changes in trunk
Thanks to Daniel Malea for helping test this patch for Linux happiness!
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185965 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 26bc105b1882a78de609d46d148ad2b5c4d50656 |
|
03-Jul-2013 |
Daniel Malea <daniel.malea@intel.com> |
Revert commits that cause broken builds on GCC buildbots
- build fails due to PyCallable template definition inside an extern "C" scope
This commit reverts 185240, 184893 and 184608.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185560 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 9c9a7bf57d081271c7e971decfe221561a920bcd |
|
26-Jun-2013 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/14266411>
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@184893 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 001cd53e9d8d9e481ada536924ea7563b84ee9cf |
|
21-Jun-2013 |
Enrico Granata <egranata@apple.com> |
In thread and frame format strings, it is now allowed to use Python functions to generate part or all of the output text
Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction})
The functions are prototyped as
def FooFunction(Object,unused)
where object is of the respective SB-type (SBTarget for target.script, ... and so on)
This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@184500 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 102b2c2681c9a830afe25bfea35557421905e42c |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 81a96aa6242f7b559770f5dc62316253cb8cb0d4 |
|
18-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
Since we use C++11, we should switch over to using std::unique_ptr when 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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 1414aba4ae30f89c2513bdbbb56c281cec014902 |
|
27-Mar-2013 |
Enrico Granata <egranata@apple.com> |
Implementing the notion of externally-acquirable ScriptInterpreter lock
With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this:
{
auto lock = interpeter->AcquireInterpreterLock();
// do whatever you need to do...
} // lock will automatically be released here
This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions
Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178189 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 36da2aa6dc5ad9994b638ed09eb81c44cc05540b |
|
25-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13069948>
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 52ebc0aab1fdecb634801deceeddd71a14c2148c |
|
19-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13010007>
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172873 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 640d5b7744750f7d37d69c6b6012549e54a711da |
|
17-Jan-2013 |
Daniel Malea <daniel.malea@intel.com> |
fix 'const const' typo introduced in r172647
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172724 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| ec1e823a9eb7ce4205a254210f633aa894fd612a |
|
16-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
Remove std::string input arguments and replace with "const char *".
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172647 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 1998778efd3b40145a70bd2a9e44da8c06b8dcd5 |
|
12-Dec-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/10898363>
Emitting a warning when defining a summary or a synthetic provider and the function/class name provided does not correspond to a valid scripting object
Also using this chance to edit a few error messages from weird "internal error" markers to actual user-legible data!
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170013 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 9ac7ce312ef8b5327a74d38edf10af86c07586b9 |
|
30-Nov-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12676084> Dump the traceback when a Python error occurs in "command script import" and the exception is not an ImportError
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169031 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| fd670c24e72a1425434020483689c3cb17f0d975 |
|
31-Oct-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation
and silence the backtrace printout
In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly
instead of having the default behavior
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@167067 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 800332c3988c78ea002b64b698f38b58ed95d3ba |
|
23-Oct-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12523238> Commit 1 of 3
This commit enables the new HasChildren() feature for synthetic children providers
Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call
Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly
Next steps are:
2) writing smart implementations of has_children for our providers whenever possible
3) make a test case
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166495 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 2e7f313dc473b036788319690116b324cb44b765 |
|
19-Oct-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12491420>
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166244 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 5b9f77786d1e9fd356e1fe2d18ce6fcd74977c98 |
|
18-Sep-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12188843> Fixing a problem where a Python command created in the same module where the target function is defined causes the help string not to come out
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164172 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| b8f126a807c00e5c2d0e7faaf764c38072cd6764 |
|
24-Aug-2012 |
Greg Clayton <gclayton@apple.com> |
The OS plug-in can now get data from a python script that implements the protocol.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162540 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 3e85b6378d312866ab25eb5623d9b8253bc498f8 |
|
24-Aug-2012 |
Enrico Granata <egranata@apple.com> |
Hooking up two more calls for the PythonOSPlugin stuff. The part of code to fetch the data and convert it to C++ objects is still missing, but will come
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162522 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 155ee91cc315888c26de1bfebd876bf35b857329 |
|
24-Aug-2012 |
Enrico Granata <egranata@apple.com> |
Adding bindings to the Script Interpreter for some basic Python OS plugin functionality (still WIP)
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162513 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| f3ec4617297810223deb545cb68214ca4dd8009c |
|
10-Aug-2012 |
Johnny Chen <johnny.chen@apple.com> |
rdar://problem/11457143 [ER] need "watchpoint command ..."
Add 'watchpoint command add/delete/list' to lldb, plus two .py test files.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@161638 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| a1ba314f3c8eb40424547836769e93f9b65e7969 |
|
07-Jun-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/11538779> Fixing issues where Python scripts were not able to read user input and/or display output to the user in certain situations - This fix introduces a Python InputReader manager class that mimics the behavior of the interactive interpreter in terms of access to I/O and ensures access to the input and output flows
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@158124 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| cf09f885c201becf51acc4a5cfac00b3df53f2a8 |
|
19-Mar-2012 |
Enrico Granata <egranata@apple.com> |
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern
Changes to synthetic children:
- the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points
this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed
- making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly)
claim to itself be synthetic
- cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible
- major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself
- removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place)
Some clean ups to the summary generation code
Centralized the code that clears out user-visible strings and data in ValueObject
More efficient summaries for libc++ containers
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153061 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 400105dd92731a0c8968d6296b0b7279b483ebf0 |
|
07-Mar-2012 |
Enrico Granata <egranata@apple.com> |
Using the new ScriptInterpreterObject in the implementation of synthetic 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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152164 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 1328b1410eb0f5e03c3b3ee302e9adca3e1b0361 |
|
29-Feb-2012 |
Enrico Granata <egranata@apple.com> |
This commit:
a) adds a Python summary provider for NSDate
b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around
c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side
d) contains much needed performance improvements:
1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time
2) redundant memory reads in the Python ObjC runtime wrapper are eliminated
3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object
e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151703 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 16376ed044df3ee70fcf69e19f06af01e71a8e9a |
|
15-Feb-2012 |
Enrico Granata <granata.enrico@gmail.com> |
<rdar://problem/10062621>
New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association.
This provides SB classes for each of the main object types involved in providing formatter support:
SBTypeCategory
SBTypeFilter
SBTypeFormat
SBTypeSummary
SBTypeSynthetic
plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions
For naming consistency, this patch also renames a lot of formatters-related classes.
Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side.
The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer.
An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes.
Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150558 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 177bc682e2b45354e8b0753e705dc84255c42173 |
|
27-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10750012>
Remove a pseudo terminal master open and slave file descriptor that was being
used for pythong stdin. It was not hooked up correctly and was causing file
descriptor leaks.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149098 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 6010acef0cee54e044d4e7e472ef3d99e13c5045 |
|
07-Nov-2011 |
Enrico Granata <granata.enrico@gmail.com> |
this patch addresses several issues with "command script" subcommands:
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
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144035 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 59df36f99b76e33852e6848a162f5c2851074ea2 |
|
17-Oct-2011 |
Enrico Granata <granata.enrico@gmail.com> |
this patch introduces a new command script import command which takes as 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
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@142283 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 915448044bac6fdac22a33cc46697dcb771a8df2 |
|
06-Sep-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Redesign of the interaction between Python and frozen objects:
- 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
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139160 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 3370f0ce9e2ae2fe1f2adf3628f443053602efa4 |
|
20-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Fixed some SWIG interoperability issues
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 13a54a141acd6255e4e11db466951ec1f26aa2f5 |
|
19-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Taking care of an issue with using lldb_private types in SBCommandInterpreter.cpp ; Making NSString test case work on Snow Leopard ; Removing an unused variable warning
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138105 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| d3a86a2bad17204570577dbafc51f3b107310de8 |
|
19-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Third round of code cleanups:
- reorganizing the PTS (Partial Template Specializations) in FormatManager.h
- applied a patch by Filipe Cabecinhas to make LLDB compile with GCC
Functional changes:
- fixed an issue where command type summary add for type "struct Foo" would not match any types.
currently, "struct" will be stripped off and type "Foo" will be matched.
similar behavior occurs for class, enum and union specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138020 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| e5e34cb15f031237004b05abfa623c71f879f6c0 |
|
17-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
When defining a scripted command, it is possible to provide a docstring and 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
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137801 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 6b1596d81c34c6efb10ed51a3572d6b145b73f5b |
|
17-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Changes to Python commands:
- 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
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137785 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| c2a2825d787be5459fc55264e55b6020ff62f68a |
|
16-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python commands:
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
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137722 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 979e20d127335143ffc89c2e37ec3a8b717ff22d |
|
29-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Public API changes:
- Completely new implementation of SBType
- Various enhancements in several other classes
Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>:
- these return the actual elements into the container as the children of the container
- basic template name parsing that works (hopefully) on both Clang and GCC
- find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth
New summary string token ${svar :
- the syntax is just the same as in ${var but this new token lets you read the values
coming from the synthetic children provider instead of the actual children
- Python providers above provide a synthetic child len that returns the number of elements
into the container
Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB
Several other fixes, including:
- inverted the order of arguments in the ClangASTType constructor
- EvaluationPoint now only returns SharedPointer's to Target and Process
- the help text for several type subcommands now correctly indicates argument-less options as such
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136504 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| e89ab7b58d2542f4f42e923fa65ef8984840a90c |
|
25-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
new flag -P to type synth add lets you type a Python class interactively
added a final newline to fooSynthProvider.py
new option to automatically save user input in InputReaderEZ
checking for NULL pointers in several new places
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135916 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 9ae7cef26612773c6b3422834cec83f0fbb2cf8c |
|
24-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python synthetic children:
- you can now define a Python class as a synthetic children producer for a type
the class must adhere to this "interface":
def __init__(self, valobj, dict):
def get_child_at_index(self, index):
def get_child_index(self, name):
then using type synth add -l className typeName
(e.g. type synth add -l fooSynthProvider foo)
(This is still WIP with lots to be added)
A small test case is available also as reference
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135865 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 9bb5b41fa3dc2421c306c21340926aaa05e6cf53 |
|
16-Jul-2011 |
Peter Collingbourne <peter@pcc.me.uk> |
Fix gcc build error
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135325 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| f7a9b14c2c02d2fa9fad586c19f29d77533fcc09 |
|
15-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python summary strings:
- you can use a Python script to write a summary string for data-types, in one of
three ways:
-P option and typing the script a line at a time
-s option and passing a one-line Python script
-F option and passing the name of a Python function
these options all work for the "type summary add" command
your Python code (if provided through -P or -s) is wrapped in a function
that accepts two parameters: valobj (a ValueObject) and dict (an LLDB
internal dictionary object). if you use -F and give a function name,
you're expected to define the function on your own and with the right
prototype. your function, however defined, must return a Python string
- test case for the Python summary feature
- a few quirks:
Python summaries cannot have names, and cannot use regex as type names
both issues will be fixed ASAP
major redesign of type summary code:
- type summary working with strings and type summary working with Python code
are two classes, with a common base class SummaryFormat
- SummaryFormat classes now are able to actively format objects rather than
just aggregating data
- cleaner code to print descriptions for summaries
the public API now exports a method to easily navigate a ValueObject hierarchy
New InputReaderEZ and PriorityPointerPair classes
Several minor fixes and improvements
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135238 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| e86cbb9ef128db87cf904e330b2edfc15566bacd |
|
22-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
Abtracted the innards of lldb-core away from the SB interface. There was some
overlap in the SWIG integration which has now been fixed by introducing
callbacks for initializing SWIG for each language (python only right now).
There was also a breakpoint command callback that called into SWIG which has
been abtracted into a callback to avoid cross over as well.
Added a new binary: lldb-platform
This will be the start of the remote platform that will use as much of the
Host functionality to do its job so it should just work on all platforms.
It is pretty hollowed out for now, but soon it will implement a platform
using the GDB remote packets as the transport.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128053 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 0aa2e55f0e9422405ad33675adc1e35044537adb |
|
14-Jan-2011 |
Caroline Tice <ctice@apple.com> |
Split up the Python script interpreter code to allow multiple script interpreter objects to
exist within the same process (one script interpreter object per debugger object). The
python script interpreter objects are all using the same global Python script interpreter;
they use separate dictionaries to keep their data separate, and mutex's to prevent any object
attempting to use the global Python interpreter when another object is already using it.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123415 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 238c0a1e7b733cee539258faa656159c63f9e893 |
|
18-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Fixed the way set/show variables were being accessed to being natively
accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.
While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.
Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114252 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 3e0571b6e8fe4cc0946529525e6a29eb0f1a8f70 |
|
11-Sep-2010 |
Johnny Chen <johnny.chen@apple.com> |
Fixed some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113673 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| d1c2dcac1c8509a77e6d9227c1285f96cbfadeb3 |
|
10-Sep-2010 |
Johnny Chen <johnny.chen@apple.com> |
Added the capability to specify a one-liner Python script as the callback
command for a breakpoint, for example:
(lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()"
The ScriptInterpreter interface has an extra method:
/// Set a one-liner as the callback for the breakpoint command.
virtual void
SetBreakpointCommandCallback (CommandInterpreter &interpreter,
BreakpointOptions *bp_options,
const char *oneliner);
to accomplish the above.
Also added a test case to demonstrate lldb's use of breakpoint callback command
to stop at function c() only when its immediate caller is function a(). The
following session shows the user entering the following commands:
1) command source .lldb (set up executable, breakpoint, and breakpoint command)
2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a())
3) bt (to see that indeed c()'s immediate caller is a())
4) c (to continue and finish the program)
test/conditional_break $ ../../build/Debug/lldb
(lldb) command source .lldb
Executing commands in '.lldb'.
(lldb) file a.out
Current executable set to 'a.out' (x86_64).
(lldb) breakpoint set -n c
Breakpoint created: 1: name = 'c', locations = 1
(lldb) script import sys, os
(lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir))
(lldb) script import conditional_break
(lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()"
(lldb) run
run
Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64)
(lldb) Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`a at main.c:25
frame #3: a.out`main at main.c:44
frame #4: a.out`start
c called from b
Continuing...
Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`main at main.c:47
frame #3: a.out`start
c called from b
Continuing...
Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`a at main.c:27
frame #2: a.out`main at main.c:50
frame #3: a.out`start
c called from a
Stopped at c() with immediate caller as a().
a(1) returns 4
b(2) returns 5
Process 20420 Stopped
* thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
36
37 int c(int val)
38 {
39 -> return val + 3;
40 }
41
42 int main (int argc, char const *argv[])
(lldb) bt
bt
thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39
frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27
frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50
frame #3: 0x0000000100000d88 a.out`start + 52
(lldb) c
c
Resuming process 20420
Process 20420 Exited
a(3) returns 6
(lldb)
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113596 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 6e4c5ce0f697eb9899a54854a2a9004e961b0de2 |
|
04-Sep-2010 |
Caroline Tice <ctice@apple.com> |
This is a very large commit that completely re-does the way lldb
handles user settable internal variables (the equivalent of set/show
variables in gdb). In addition to the basic infrastructure (most of
which is defined in UserSettingsController.{h,cpp}, there are examples
of two classes that have been set up to contain user settable
variables (the Debugger and Process classes). The 'settings' command
has been modified to be a command-subcommand structure, and the 'set',
'show' and 'append' commands have been moved into this sub-commabnd
structure. The old StateVariable class has been completely replaced
by this, and the state variable dictionary has been removed from the
Command Interpreter. Places that formerly accessed the state variable
mechanism have been modified to access the variables in this new
structure instead (checking the term-width; getting/checking the
prompt; etc.)
Variables are attached to classes; there are two basic "flavors" of
variables that can be set: "global" variables (static/class-wide), and
"instance" variables (one per instance of the class). The whole thing
has been set up so that any global or instance variable can be set at
any time (e.g. on start up, in your .lldbinit file), whether or not
any instances actually exist (there's a whole pending and default
values mechanism to help deal with that).
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113041 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 60dde64d699c71807dc95d75b40f5b777d167cc4 |
|
31-Jul-2010 |
Johnny Chen <johnny.chen@apple.com> |
We can do better when reporting the status of one-liner script execution.
Change the prototype of ScriptInterpreter::ExecuteOneLine() to return bool
instead of void and take one additional parameter as CommandReturnObject *.
Propagate the status of one-liner execution back appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@109899 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| bef1583b89e73de77c8b0897fcf42b5b1fcabe4c |
|
14-Jul-2010 |
Greg Clayton <gclayton@apple.com> |
I enabled some extra warnings for hidden local variables and for hidden
virtual functions and caught some things and did some general code cleanup.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@108299 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 63094e0bb161580564954dee512955c1c79d3476 |
|
23-Jun-2010 |
Greg Clayton <gclayton@apple.com> |
Very large changes that were needed in order to allow multiple connections
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.
To avoid this we now create instances of the lldb_private::Debugger that each
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack
So now clients should call:
SBDebugger::Initialize(); // (static function)
SBDebugger debugger (SBDebugger::Create());
// Use which ever file handles you wish
debugger.SetErrorFileHandle (stderr, false);
debugger.SetOutputFileHandle (stdout, false);
debugger.SetInputFileHandle (stdin, true);
// main loop
SBDebugger::Terminate(); // (static function)
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.
Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@106615 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| dea5ea78ef9bf371a0d19590c6b7c6989cba9a89 |
|
09-Jun-2010 |
Jason Molenda <jmolenda@apple.com> |
Move source/Utility/PseudoTerminal.h into include/lldb/Utility.
The top of the header file seems to indicate that this was
intended to be over at include/lldb/Core but we should be in line
with the .cpp file's location so it's include/lldb/Utility for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105753 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|
| 24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Interpreter/ScriptInterpreter.h
|