Commit Graph

36 Commits

Author SHA1 Message Date
Enrico Granata 8387e2fafe Add a (Python only) lldb.SBSyntheticValueProvider class to our API surface
On a suggestion from Jim Ingham, this class allows you to very easily define synthetic child providers that return a synthetic value (in the sense of r219330), but no children

Also, document this new feature in our www docs

llvm-svn: 219337
2014-10-08 20:10:09 +00:00
Todd Fiala 732215f989 Add support for inspecting enum members.
Change by Russell Harmon.

Xcode project updates (and all errors therein)
by Todd Fiala.

llvm-svn: 210046
2014-06-02 20:55:29 +00:00
Greg Clayton 44d937820b Merging the iohandler branch back into main.
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
2014-01-27 23:43:24 +00:00
Greg Clayton 226cce2511 Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:

lldb::SBModuleSpec
lldb::SBModuleSpecList

The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.

llvm-svn: 185877
2013-07-08 22:22:41 +00:00
Greg Clayton d8c3d4b1e9 Implemented a types.py module that allows types to be inspected for padding.
The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.

llvm-svn: 184364
2013-06-19 21:50:28 +00:00
Greg Clayton 88e0f618ea Added a new decorator function in the "lldb" module that can register a command automatically. We have just a few kinks to work out for the Xcode workflow and we will be ready to switch over to using this. To use this, you can decorate your python function as:
@lldb.command("new_command", "Documentation string for new_command...")
def new_command(debugger, command, result, dict):
    ....
    
No more need to register your command in the __lldb_init_module function!

llvm-svn: 184274
2013-06-19 01:38:02 +00:00
Enrico Granata c3387333ce <rdar://problem/11742979>
SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation
But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out
The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-)
Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both

llvm-svn: 180987
2013-05-03 01:29:27 +00:00
Greg Clayton dda8c7d56f Fixed SBValueList to have a __str__ function like all other SB classes. Previously this was done as __repr__.
llvm-svn: 179327
2013-04-11 22:24:25 +00:00
Enrico Granata ac9df2d1a6 <rdar://problem/13434476>
Making value objects properly iterable in constructs of the form
[ x for x in value_with_children ]

This would previously cause an endless loop because lacking a proper iterator object, Python will keep calling __getitem__() with increasing values of the index until it gets an IndexError
since SBValue::GetValueForExpressionPath() supports synthetic array members, no array index will ever really cause an IndexError to be raised, hence the endless iteration

class value_iter is an implementation of __iter__() that provides a terminating iterator over a value

llvm-svn: 177885
2013-03-25 18:53:07 +00:00
Enrico Granata ceba071330 - Masking out SBCommandReturnObject::Printf() from the Python layer because SWIG and varargs do not get along well.
It is replaced by a Print("str") call which is equivalent to Printf("%s","str")
- Providing file-like behavior for SBStream with appropriate extension write() and flush() calls, plus documenting that these are only meant and only exist for Python
Documenting the file-like behavior on our website

llvm-svn: 177877
2013-03-25 17:37:39 +00:00
Enrico Granata 7d1f93942f <rdar://problem/13312903>
Exports write() and flush() from SBCommandReturnObject to enable file-like output from Python commands.
e.g.:
def ls(debugger, command, result, internal_dict):
    print >>result,”just “some output”

will produce
(lldb) ls
just “some output
(lldb) 

llvm-svn: 177807
2013-03-23 01:35:44 +00:00
Enrico Granata 10de09044e <rdar://problem/12462744> Implement a new SBDeclaration class to wrap an lldb_private::Declaration - make a GetDeclaration() API on SBValue to return a declaration. This will only work for vroot variables as they are they only objects for which we currently provide a valid Declaration
llvm-svn: 165672
2012-10-10 22:54:17 +00:00
Enrico Granata f75c976928 Silly me! There was a closing ) missing from one of the lines - and Python complained about syntax errors on the next line. It being a Friday afternoon made the rest
llvm-svn: 165420
2012-10-08 19:01:10 +00:00
Enrico Granata 944b4c4c1b Retrying to apply Vishal's patch - hopefully this time it won't break Jason's build
llvm-svn: 165410
2012-10-08 17:32:55 +00:00
Jason Molenda cc62f28735 Revert Vishal's patch that Enrico commited, at least for the weekend. With it applied,
starting lldb I get

% ./lldb -x
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/private/tmp/build/Debug/LLDB.framework/Versions/A/Resources/Python/lldb/__init__.py", line 9008
    raise TypeError("No array item of type %s" % str(type(key)))
        ^
SyntaxError: invalid syntax
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
(lldb)


I did a clean build and still got the problem so I'm backing this out until Enrico can
look at it.

llvm-svn: 165356
2012-10-06 01:46:12 +00:00
Enrico Granata ffe2d52a06 patch from Vishal Patel to improve our lldb.value wrapper
llvm-svn: 165348
2012-10-06 00:06:18 +00:00
Enrico Granata cd29fefbff <rdar://problem/12442990> Fix the implementation of lldb.value.__eq__
llvm-svn: 165344
2012-10-05 23:20:58 +00:00
Filipe Cabecinhas c5041918dd Added SBDebugger's log callbacks to Python-land
- Tweaked a parameter name in SBDebugger.h so my typemap will catch it;
- Added a SBDebugger.Create(bool, callback, baton) to the swig interface;
- Added SBDebugger.SetLoggingCallback to the swig interface;
- Added a callback utility function for log callbacks;
- Guard against Py_None on both callback utility functions;

- Added a FIXME to the SBDebugger API test;
- Added a __del__() stub for SBDebugger.

We need to be able to get both the log callback and baton from an
SBDebugger if we want to protect against memory leaks (or make the user
responsible for holding another reference to the callback).
Additionally, it's impossible to revert from a callback-backed log
mechanism to a file-backed log mechanism.

llvm-svn: 162633
2012-08-25 00:29:07 +00:00
Filipe Cabecinhas 6eb31e7391 Added a typemap and wrappers for SBInputReader callbacks
Now it's possible to use SBInputReader callbacks in Python.

We leak the callback object, unfortunately. A __del__ method can be added
to SBInputReader, but we have no way to check the callback function that
is on the reader. So we can't call Py_DECREF on it when we have our
PythonCallback function. One way to do it is to assume that reified
SBInputReaders always have a Python callback (and always call Py_DECREF).
Another one is to add methods or properties to SBInputReader (or make the
m_callback_function property public).

llvm-svn: 162356
2012-08-22 13:25:10 +00:00
Enrico Granata 061858ce61 <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.

llvm-svn: 150558
2012-02-15 02:34:21 +00:00
Greg Clayton 5569e64ea7 Removed all of the "#ifndef SWIG" from the SB header files since we are using
interface (.i) files for each class.

Changed the FindFunction class from:

uint32_t
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

uint32_t
SBModule::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

To:

lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.

Exposed properties for lldb.SBSymbolContextList in python:

lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list

This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:

sc_list = lldb.target.FindFunctions("erase")

for function in sc_list.functions:
    print function
for symbol in sc_list.symbols:
    print symbol

Exposed properties for the lldb.SBSymbolContext objects in python:

lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol


Exposed properties for the lldb.SBBlock objects in python:

lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok

SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.

SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:

lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
                       bool arguments,
                       bool locals,
                       bool statics,
                       lldb::DynamicValueType use_dynamic);

lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
                       bool arguments,
                       bool locals,
                       bool statics);

When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.

When a SBTarget is used, global an static variables can be viewed without a
running process.

llvm-svn: 149853
2012-02-06 01:44:54 +00:00
Greg Clayton 81e871ed76 Convert all python objects in our API to use overload the __str__ method
instead of the __repr__. __repr__ is a function that should return an
expression that can be used to recreate an python object and we were using
it to just return a human readable string.

Fixed a crasher when using the new implementation of SBValue::Cast(SBType).

Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general
improvements to the API.

Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't
correctly handle not having a target.

llvm-svn: 149743
2012-02-04 02:27:34 +00:00
Greg Clayton 7edbdfc97c Expose more convenience functionality in the python classes.
lldb.SBValueList now exposes the len() method and also allows item access:

lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range
lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches)
lldb.SBValueList[<re>]  - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches

lldb.SBFrame now exposes:

lldb.SBFrame.variables => SBValueList of all variables that are in scope
lldb.SBFrame.vars => see lldb.SBFrame.variables
lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame
lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame
lldb.SBFrame.args => see lldb.SBFrame.arguments
lldb.SBFrame.statics => SBValueList of all static variables
lldb.SBFrame.registers => SBValueList of all registers for the current frame
lldb.SBFrame.regs => see lldb.SBFrame.registers

Combine any of the above properties with the new lldb.SBValueList functionality
and now you can do:

y = lldb.frame.vars['rect.origin.y']

or

vars = lldb.frame.vars
for i in range len(vars):
  print vars[i]

Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path
for any variable or child within the variable. This makes it easier to get a
value from the current frame like "rect.origin.y". The resulting value is also
not a constant result as expressions will return, but a live value that will
continue to track the current value for the variable expression path.

lldb.SBValue now exposes:

lldb.SBValue.unsigned => unsigned integer for the value
lldb.SBValue.signed => a signed integer for the value

llvm-svn: 149684
2012-02-03 07:02:37 +00:00
Greg Clayton 43484c5cd7 When outputting hex values use unsigned integer values so we don't get
negative hex values. Also added a very rudimentary version of the == and !=
operators to the lldb.value helper class.

llvm-svn: 149564
2012-02-02 00:12:47 +00:00
Greg Clayton 2415586faa Added a new convenience property on lldb.SBThread names "frames" which always returns a complete list of all lldb.SBFrame objects:
(lldb) script
>>> frames = lldb.thread.frames
>>> for frame in frames:
...   print frame

Also changed all of the "__repr__" methods to strip any trailing newline characters so we don't end up with entra newlines.

llvm-svn: 149466
2012-02-01 02:30:27 +00:00
Greg Clayton 05e8d19446 Added a new class to the lldb python module:
lldb.value()

It it designed to be given a lldb.SBValue object and it allows natural
use of a variable value:

    pt = lldb.value(lldb.frame.FindVariable("pt"))
    print pt
    print pt.x
    print pt.y

    pt = lldb.frame.FindVariable("rectangle_array")
    print rectangle_array[12]
    print rectangle_array[5].origin.x

Note that array access works just fine and works on arrays or pointers:

pt = lldb.frame.FindVariable("point_ptr")
print point_ptr[5].y

Also note that pointer child accesses are done using a "." instead of "->":

print point_ptr.x

llvm-svn: 149464
2012-02-01 01:46:19 +00:00
Greg Clayton da7bc7d000 <rdar://problem/10126482>
Fixed an issues with the SBType and SBTypeMember classes:
- Fixed SBType to be able to dump itself from python
- Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces
- Fixed SBTypeMember to be able to dump itself from python
- Fixed the SBTypeMember ability to get a field offset in bytes (the value
  being returned was wrong)
- Added the SBTypeMember ability to get a field offset in bits


Cleaned up a lot of the Stream usage in the SB API files.

llvm-svn: 144493
2011-11-13 06:57:31 +00:00
Greg Clayton 1b282f9619 Cleaned up the SBWatchpoint public API.
llvm-svn: 141876
2011-10-13 18:08:26 +00:00
Johnny Chen d4dd7993b5 Export the watchpoint related API (SBWatchpointLocation class and added SBTarget methods)
to the Python interface.

Implement yet another (threre're 3 now) iterator protocol for SBTarget: watchpoint_location_iter(),
to iterate on the available watchpoint locations.  And add a print representation for
SBWatchpointLocation.

Exercise some of these Python API with TestWatchpointLocationIter.py.

llvm-svn: 140595
2011-09-27 01:19:20 +00:00
Greg Clayton d9dc52dc4c Added the ability to get all section contents, or the section
contents starting at an offset (2 separate methods). This helps
the scripting interface stay more natural by allowing both from
Python.

Added the ability to dump data with address annotations when
call SBData::GetDescription().

Hooked up the SBSection to the __repr__ so you can print section
objects from within python.

Improved the dumping of symbols from python.

Fixed the .i interface references which were set to "Relative to this Group"
which somehow included Jim's "lldb-clean" root directory in the path. The
interfaces are now in a folder called "interfaces" withing the Xcode API
subfolder.

llvm-svn: 140451
2011-09-24 05:04:40 +00:00
Enrico Granata 9128ee2f7a 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

llvm-svn: 139160
2011-09-06 19:20:51 +00:00
Johnny Chen fc87e2dd5c Make SBBreakpointLocation::GetDescription() API to be consistent with SBTarget,
i.e., with 'SBStream &description' first, followed by 'DescriptionLevel level'.

Modify lldbutil.py so that get_description() for a target or breakpoint location
can just take the lldb object itself without specifying an option to mean option
lldb.eDescriptionLevelBrief.  Modify TestTargetAPI.py to exercise this logic path.

llvm-svn: 130147
2011-04-25 20:23:05 +00:00
Caroline Tice ceb6b1393d First pass at adding logging capabilities for the API functions. At the moment
it logs the function calls, their arguments and the return values.  This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done.  It currently does not
attempt to log all the functions, just the most important ones.  I will be 
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).


Update the Python build scripts to re-build the swig C++ file whenever 
the python-extensions.swig file is modified.

Correct the help for 'log enable' command (give it the correct number & type of
arguments).

llvm-svn: 117349
2010-10-26 03:11:13 +00:00
Greg Clayton 05faeb7135 Cleaned up the SWIG stuff so all includes happen as they should, no pulling
tricks to get types to resolve. I did this by correctly including the correct
files: stdint.h and all lldb-*.h files first before including the API files.
This allowed me to remove all of the hacks that were in the lldb.swig file
and it also allows all of the #defines in lldb-defines.h and enumerations
in lldb-enumerations.h to appear in the lldb.py module. This will make the
python script code a lot more readable.

Cleaned up the "process launch" command to not execute a "process continue"
command, it now just does what it should have with the internal API calls
instead of executing another command line command.

Made the lldb_private::Process set the state to launching and attaching if
WillLaunch/WillAttach return no error respectively.

llvm-svn: 115902
2010-10-07 04:19:01 +00:00
Greg Clayton 1d27316606 Added the ability to get the disassembly instructions from the function and
symbol.

llvm-svn: 115734
2010-10-06 03:09:58 +00:00
Caroline Tice dac97f31a3 Remove all the __repr__ methods from the API/*.h files, and put them
into python-extensions.swig, which gets included into lldb.swig, and
adds them back into the classes when swig generates it's C++ file.  This
keeps the Python stuff out of the general API classes.

Also fixed a small bug in the copy constructor for SBSymbolContext.

llvm-svn: 114602
2010-09-22 23:01:29 +00:00