summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/python-extensions.swig
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/Bindings] Move bindings into their own subdirectoryJonas Devlieghere2020-01-091-592/+0
| | | | | | | | | | | | All the code required to generate the language bindings for Python and Lua lives under scripts, even though the majority of this code aren't scripts at all, and surrounded by scripts that are totally unrelated. I've reorganized these files and moved everything related to the language bindings into a new top-level directory named bindings. This makes the corresponding files self contained and much more discoverable. Differential revision: https://reviews.llvm.org/D72437
* [lldb/SWIG] Refactor extensions to be non Python-specific (3/3)Jonas Devlieghere2020-01-081-253/+4
| | | | | | | | | | | The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. It uses a SWIG macro to reduce code duplication. Differential revision: https://reviews.llvm.org/D72377
* [lldb/SWIG] Refactor extensions to be non Python-specific (2/2)Jonas Devlieghere2020-01-081-272/+4
| | | | | | | | | | | The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. It uses a SWIG macro to reduce code duplication. Differential revision: https://reviews.llvm.org/D72377
* [lldb/SWIG] Refactor extensions to be non Python-specificJonas Devlieghere2020-01-081-13/+0
| | | | | | | | | | | The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. Differential revision: https://reviews.llvm.org/D72377
* Revert "Re-land "[lldb/Lua] Add string conversion operator for SBTarget.""Jonas Devlieghere2020-01-071-0/+12
| | | | | | This was returning a pointer to a stack-allocated memory location. This works for Python where we return a PythonString which must own the underlying string.
* Re-land "[lldb/Lua] Add string conversion operator for SBTarget."Jonas Devlieghere2020-01-071-12/+0
| | | | | | | Extend the SBTarget class with a string conversion operator and reuse the same code between Python and Lua. This should happen for all the SB classes, but I'm doing just this one as an example and for use in a test case.
* Revert "[lldb/Lua] Add string conversion operator for SBTarget."Jonas Devlieghere2020-01-071-0/+12
| | | | This reverts commit 640d0ba8760051afc002c672121c6989517fc94e.
* [lldb/Lua] Add string conversion operator for SBTarget.Jonas Devlieghere2020-01-071-12/+0
| | | | | | | Extend the SBTarget class with a string conversion operator and reuse the same code between Python and Lua. This should happen for all the SB classes, but I'm doing just this one as an example and for use in a test case.
* remove multi-argument form of PythonObject::Reset()Lawrence D'Anna2019-10-221-164/+41
| | | | | | | | | | | | | | | | | | | | Summary: With this patch, only the no-argument form of `Reset()` remains in PythonDataObjects. It also deletes PythonExceptionState in favor of PythonException, because the only call-site of PythonExceptionState was also using Reset, so I cleaned up both while I was there. Reviewers: JDevlieghere, clayborg, labath, jingham Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69214 llvm-svn: 375475
* [Python] Implement __next__ for value_iterJonas Devlieghere2019-09-041-1/+4
| | | | | | | | | Python 3 iteration calls the next() method instead of next() and value_iter only implemented the Python 2 version. Differential revision: https://reviews.llvm.org/D67184 llvm-svn: 370954
* [Python] Implement truth testing for lldb.valueJonas Devlieghere2019-09-041-0/+3
| | | | | | | | | Python 3 calls __bool__() instead of __len__() and lldb.value only implemented the __len__ method. This adds the __bool__() implementation. Differential revision: https://reviews.llvm.org/D67183 llvm-svn: 370953
* [Python] Fix whitespace before making changes (NFC)Jonas Devlieghere2019-09-041-164/+164
| | | | llvm-svn: 370952
* Hold GIL while allocating memory for PythonString.Tatyana Krasnukha2018-09-051-0/+82
| | | | | | | | | | | | | | Summary: Swig wraps C++ code into SWIG_PYTHON_THREAD_BEGIN_ALLOW; ... SWIG_PYTHON_THREAD_END_ALLOW; Thus, LLDB crashes with "Fatal Python error: Python memory allocator called without holding the GIL" when calls an lldb_SB***___str__ function. Reviewers: clayborg Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D51569 llvm-svn: 341482
* Fix and simplify lldb.command decoratorDave Lee2018-07-041-19/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes one issue with `lldb.command`, and also reduces the implementation. The fix: a command function's docstring was not shown when running `help <command_name>`. This is because the docstring attached the source function is not propagated to the decorated function (`f.__call__`). By returning the original function, the docstring will be properly displayed by `help`. Also with this change, the command name is assumed to be the function's name, but can still be explicitly defined as previously. Additionally, the implementation was updated to: * Remove inner class * Remove use of `inspect` module * Remove `*args` and `**kwargs` Reviewers: clayborg Reviewed By: clayborg Subscribers: keith, xiaobai, lldb-commits Differential Revision: https://reviews.llvm.org/D48658 llvm-svn: 336287
* Make breakpoint names real entities.Jim Ingham2017-09-141-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When introduced, breakpoint names were just tags that you could apply to breakpoints that would allow you to refer to a breakpoint when you couldn't capture the ID, or to refer to a collection of breakpoints. This change makes the names independent holders of breakpoint options that you can then apply to breakpoints when you add the name to the breakpoint. It adds the "breakpoint name configure" command to set up or reconfigure breakpoint names. There is also full support for then in the SB API, including a new SBBreakpointName class. The connection between the name and the breakpoints sharing the name remains live, so if you reconfigure the name, all the breakpoint options all change as well. This allows a quick way to share complex breakpoint behavior among a bunch of breakpoints, and a convenient way to iterate on the set. You can also create a name from a breakpoint, allowing a quick way to copy options from one breakpoint to another. I also added the ability to make hidden and delete/disable protected names. When applied to a breakpoint, you will only be able to list, delete or disable that breakpoint if you refer to it explicitly by ID. This feature will allow GUI's that need to use breakpoints for their own purposes to keep their breakpoints from getting accidentally disabled or deleted. <rdar://problem/22094452> llvm-svn: 313292
* Add .i files for SBMemoryRegionInfo and SBMemoryRegionInfoList and also hook ↵Greg Clayton2016-06-241-0/+16
| | | | | | | | up the new calls in SBProcess that give out SBMemoryRegionInfo and SBMemoryRegionInfoList objects. Also make sure the right headers and .i files are included so SWIG can hook everything up. llvm-svn: 273749
* Fix an issue where the @lldb.command marker would not work with the new ↵Enrico Granata2016-06-241-4/+9
| | | | | | | | | | | 5-argument version of the Python command function This: a) teaches PythonCallable to look inside a callable object b) teaches PythonCallable to discover whether a callable method is bound c) teaches lldb.command to dispatch to either the older 4 argument version or the newer 5 argument version llvm-svn: 273640
* Change lldb.value.__int__() so that it takes into account the signedness of ↵Enrico Granata2016-02-101-3/+48
| | | | | | | | | | the value being cast to return a Python number with the proper value The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless Fixes rdar://24556976 llvm-svn: 260349
* __ne__ is the actual Python operator; __neq__ is a typoEnrico Granata2015-12-181-1/+1
| | | | llvm-svn: 256053
* Fixed TypeMemberFunctionImpl to not use clang types directly but use the new ↵Greg Clayton2015-11-101-0/+14
| | | | | | | | | | CompilerDecl class to do the job in an abstract way. Fixed a crash that would happen if you tried to get the name of a constructor or destructor by calling "getDeclName()" instead of calling getName() (which would assert and crash). Added the ability to get function arguments names from SBFunction. llvm-svn: 252622
* Change swig interface files to use PythonDataObjects.Zachary Turner2015-10-141-76/+76
| | | | llvm-svn: 250303
* Add a (Python only) lldb.SBSyntheticValueProvider class to our API surfaceEnrico Granata2014-10-081-0/+24
| | | | | | | | 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
* Add support for inspecting enum members.Todd Fiala2014-06-021-0/+14
| | | | | | | | | Change by Russell Harmon. Xcode project updates (and all errors therein) by Todd Fiala. llvm-svn: 210046
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-9/+0
| | | | | | | | | | | | 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
* Added a way to extract the module specifications from a file. A module ↵Greg Clayton2013-07-081-0/+31
| | | | | | | | | | | | | 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
* Implemented a types.py module that allows types to be inspected for padding.Greg Clayton2013-06-191-2/+2
| | | | | | 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
* Added a new decorator function in the "lldb" module that can register a ↵Greg Clayton2013-06-191-0/+20
| | | | | | | | | | | | 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
* <rdar://problem/11742979>Enrico Granata2013-05-031-0/+211
| | | | | | | | | 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
* Fixed SBValueList to have a __str__ function like all other SB classes. ↵Greg Clayton2013-04-111-2/+3
| | | | | | Previously this was done as __repr__. llvm-svn: 179327
* <rdar://problem/13434476>Enrico Granata2013-03-251-4/+31
| | | | | | | | | | | | 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
* - Masking out SBCommandReturnObject::Printf() from the Python layer because ↵Enrico Granata2013-03-251-0/+20
| | | | | | | | | | 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
* <rdar://problem/13312903>Enrico Granata2013-03-231-0/+7
| | | | | | | | | | | | | | 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
* <rdar://problem/12462744> Implement a new SBDeclaration class to wrap an ↵Enrico Granata2012-10-101-0/+14
| | | | | | 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
* Silly me! There was a closing ) missing from one of the lines - and Python ↵Enrico Granata2012-10-081-1/+1
| | | | | | complained about syntax errors on the next line. It being a Friday afternoon made the rest llvm-svn: 165420
* Retrying to apply Vishal's patch - hopefully this time it won't break ↵Enrico Granata2012-10-081-12/+20
| | | | | | Jason's build llvm-svn: 165410
* Revert Vishal's patch that Enrico commited, at least for the weekend. With ↵Jason Molenda2012-10-061-20/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* patch from Vishal Patel to improve our lldb.value wrapperEnrico Granata2012-10-061-11/+20
| | | | llvm-svn: 165348
* <rdar://problem/12442990> Fix the implementation of lldb.value.__eq__Enrico Granata2012-10-051-1/+9
| | | | llvm-svn: 165344
* Added SBDebugger's log callbacks to Python-landFilipe Cabecinhas2012-08-251-1/+9
| | | | | | | | | | | | | | | | | | | - 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
* Added a typemap and wrappers for SBInputReader callbacksFilipe Cabecinhas2012-08-221-1/+10
| | | | | | | | | | | | | | 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
* <rdar://problem/10062621>Enrico Granata2012-02-151-0/+84
| | | | | | | | | | | | | | | | | | 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
* Removed all of the "#ifndef SWIG" from the SB header files since we are usingGreg Clayton2012-02-061-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Convert all python objects in our API to use overload the __str__ methodGreg Clayton2012-02-041-55/+79
| | | | | | | | | | | | | | | | 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
* Expose more convenience functionality in the python classes.Greg Clayton2012-02-031-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* When outputting hex values use unsigned integer values so we don't getGreg Clayton2012-02-021-2/+7
| | | | | | | negative hex values. Also added a very rudimentary version of the == and != operators to the lldb.value helper class. llvm-svn: 149564
* Added a new convenience property on lldb.SBThread names "frames" which ↵Greg Clayton2012-02-011-26/+182
| | | | | | | | | | | | | 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
* Added a new class to the lldb python module:Greg Clayton2012-02-011-0/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/10126482>Greg Clayton2011-11-131-0/+14
| | | | | | | | | | | | | | | 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
* Cleaned up the SBWatchpoint public API.Greg Clayton2011-10-131-2/+2
| | | | llvm-svn: 141876
* Export the watchpoint related API (SBWatchpointLocation class and added ↵Johnny Chen2011-09-271-0/+7
| | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud