Summary:
Move scripts/Python/interface to scripts/interface so that we
can start making iterative improvements towards sharing the
interface files between multiple languages (each of which would
have their own directory as now).
Test Plan: Build and see.
Reviewers: zturner, emaste, clayborg
Reviewed By: clayborg
Subscribers: mjsabby, lldb-commits
Differential Revision: http://reviews.llvm.org/D9212
llvm-svn: 235676
Reverting this commit led to other failures which I did not see at
first. This turned out to be an easy problem to fix, so I added
SBVariablesOptions.cpp to the CMakeLists.txt. In the future please
try to make sure new files are added to CMake.
llvm-svn: 229516
We talked about it internally - and came to the conclusion that it's time to have an options class
This commit adds an SBVariablesOptions class and goes through all the required dance
llvm-svn: 228975
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
See http://reviews.llvm.org/D4221 for details.
This commit allows you to control the signals that lldb will suppress, stop or forward using the Python and C++ APIs.
Change by Russell Harmon.
Xcode build system changes (and any mistakes) by Todd Fiala. Tested on MacOSX 10.9.3 and Xcode 6 beta. (Xcode 5 is hitting the dependency checker crasher on all my systems).
llvm-svn: 211526
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
libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the
documentation and testing of these but the overall API is settling down so it's
a good time to check it in.
<rdar://problem/15600370>
llvm-svn: 197190
Example code:
remote_platform = lldb.SBPlatform("remote-macosx");
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)
connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111");
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
print >> result, 'Connected to remote platform:'
print >> result, 'hostname: %s' % (remote_platform.GetHostname())
src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
dst = lldb.SBFileSpec()
# copy src to platform working directory since "dst" is empty
err = remote_platform.Install(src, dst);
if err.Success():
print >> result, '%s installed successfully' % (src)
else:
print >> result, 'error: failed to install "%s": %s' % (src, err)
Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.
The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.
The API in SBPlatform is subject to change and will be getting many new functions.
llvm-svn: 195273
GetThreadOriginExtendedBacktraceTypeAtIndex methods to
SBProcess.
Add documentation for the GetQueueName and GetQueueID methods
to SBThread.
<rdar://problem/15314369>
llvm-svn: 194063
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
Any time a SWIG wrapper needs a PyObject for an SB object, it now should call into SBTypeToSWIGWrapper<SBType>(SBType*)
If you try to use it on an SBType for which there is not an implementation yet, LLDB will fail to link - just add your specialization to python-swigsafecast.swig and rebuild
This is the first step in simplifying our SWIG Wrapper layer
llvm-svn: 184580
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
You can now access a frame in a thread using:
lldb.SBThread.frame[int] -> lldb.SBFrame object for a frame in a thread
Where "int" is an integer index. You can also access a list object with all of
the frames using:
lldb.SBThread.frames => list() of lldb.SBFrame objects
All SB objects that give out SBAddress objects have properties named "addr"
lldb.SBInstructionList now has the following convenience accessors for len() and
instruction access using an index:
insts = lldb.frame.function.instructions
for idx in range(len(insts)):
print insts[idx]
Instruction lists can also lookup an isntruction using a lldb.SBAddress as the key:
pc_inst = lldb.frame.function.instructions[lldb.frame.addr]
lldb.SBProcess now exposes:
lldb.SBProcess.is_alive => BOOL Check if a process is exists and is alive
lldb.SBProcess.is_running => BOOL check if a process is running (or stepping):
lldb.SBProcess.is_running => BOOL check if a process is currently stopped or crashed:
lldb.SBProcess.thread[int] => lldb.SBThreads for a given "int" zero based index
lldb.SBProcess.threads => list() containing all lldb.SBThread objects in a process
SBInstruction now exposes:
lldb.SBInstruction.mnemonic => python string for instruction mnemonic
lldb.SBInstruction.operands => python string for instruction operands
lldb.SBInstruction.command => python string for instruction comment
SBModule now exposes:
lldb.SBModule.uuid => uuid.UUID(), an UUID object from the "uuid" python module
lldb.SBModule.symbol[int] => lldb.Symbol, lookup symbol by zero based index
lldb.SBModule.symbol[str] => list() of lldb.Symbol objects that match "str"
lldb.SBModule.symbol[re] => list() of lldb.Symbol objecxts that match the regex
lldb.SBModule.symbols => list() of all symbols in a module
SBAddress objects can now access the current load address with the "lldb.SBAddress.load_addr"
property. The current "lldb.target" will be used to try and resolve the load address.
Load addresses can also be set using this accessor:
addr = lldb.SBAddress()
addd.load_addr = 0x123023
Then you can check the section and offset to see if the address got resolved.
SBTarget now exposes:
lldb.SBTarget.module[int] => lldb.SBModule from zero based module index
lldb.SBTarget.module[str] => lldb.SBModule by basename or fullpath or uuid string
lldb.SBTarget.module[uuid.UUID()] => lldb.SBModule whose UUID matches
lldb.SBTarget.module[re] => list() of lldb.SBModule objects that match the regex
lldb.SBTarget.modules => list() of all lldb.SBModule objects in the target
SBSymbol now exposes:
lldb.SBSymbol.name => python string for demangled symbol name
lldb.SBSymbol.mangled => python string for mangled symbol name or None if there is none
lldb.SBSymbol.type => lldb.eSymbolType enum value
lldb.SBSymbol.addr => SBAddress object that represents the start address for this symbol (if there is one)
lldb.SBSymbol.end_addr => SBAddress for the end address of the symbol (if there is one)
lldb.SBSymbol.prologue_size => pythin int containing The size of the prologue in bytes
lldb.SBSymbol.instructions => SBInstructionList containing all instructions for this symbol
SBFunction now also has these new properties in addition to what is already has:
lldb.SBFunction.addr => SBAddress object that represents the start address for this function
lldb.SBFunction.end_addr => SBAddress for the end address of the function
lldb.SBFunction.instructions => SBInstructionList containing all instructions for this function
SBFrame now exposes the SBAddress for the frame:
lldb.SBFrame.addr => SBAddress which is the section offset address for the current frame PC
These are all in addition to what was already added. Documentation and website
updates coming soon.
llvm-svn: 149489
all RTTI types, and since we don't use RTTI anymore since clang and llvm don't
we don't really need this header file. All shared pointer definitions have
been moved into "lldb-forward.h".
Defined std::tr1::weak_ptr definitions for all of the types that inherit from
enable_shared_from_this() in "lldb-forward.h" in preparation for thread
hardening our public API.
The first in the thread hardening check-ins. First we start with SBThread.
We have issues in our lldb::SB API right now where if you have one object
that is being used by two threads we have a race condition. Consider the
following code:
1 int
2 SBThread::SomeFunction()
3 {
4 int result = -1;
5 if (m_opaque_sp)
6 {
7 result = m_opaque_sp->DoSomething();
8 }
9 return result;
10 }
And now this happens:
Thread 1 enters any SBThread function and checks its m_opaque_sp and is about
to execute the code on line 7 but hasn't yet
Thread 2 gets to run and class sb_thread.Clear() which calls m_opaque_sp.clear()
and clears the contents of the shared pointer member
Thread 1 now crashes when it resumes.
The solution is to use std::tr1::weak_ptr. Now the SBThread class contains a
lldb::ThreadWP (weak pointer to our lldb_private::Thread class) and this
function would look like:
1 int
2 SBThread::SomeFunction()
3 {
4 int result = -1;
5 ThreadSP thread_sp(m_opaque_wp.lock());
6 if (thread_sp)
7 {
8 result = m_opaque_sp->DoSomething();
9 }
10 return result;
11 }
Now we have a solid thread safe API where we get a local copy of our thread
shared pointer from our weak_ptr and then we are guaranteed it can't go away
during our function.
So lldb::SBThread has been thread hardened, more checkins to follow shortly.
llvm-svn: 149218
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
- New SBSection objects that are object file sections which can be accessed
through the SBModule classes. You can get the number of sections, get a
section at index, and find a section by name.
- SBSections can contain subsections (first find "__TEXT" on darwin, then
us the resulting SBSection to find "__text" sub section).
- Set load addresses for a SBSection in the SBTarget interface
- Set the load addresses of all SBSection in a SBModule in the SBTarget interface
- Add a new module the an existing target in the SBTarget interface
- Get a SBSection from a SBAddress object
This should get us a lot closer to being able to symbolicate using LLDB through
the public API.
llvm-svn: 140437
Fix the RegularExpression class so it has a real copy constructor.
Fix the breakpoint setting with multiple shared libraries so it makes
one breakpoint not one per shared library.
Add SBFileSpecList, to be used to expose the above to the SB interface (not done yet.)
llvm-svn: 140225
- 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
- They now have an SBCommandReturnObject instead of an SBStream as third argument
- The class CommandObjectPythonFunction has been merged into CommandObjectCommands.cpp
- The command to manage them is now:
command script with subcommands add, list, delete, clear
command alias is returned to its previous functionality
- Python commands are now part of an user dictionary, instead of being seen as aliases
llvm-svn: 137785
- 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
llvm-svn: 135865
of the duty of having SWIG docstring features and multiline string literals
embedded within.
lldb.swig now %include .../SBTarget.i, instead of .../SBTarget.h. Will create
other interface files and transition them over.
Also update modify-python-lldb.py to better handle the trailing blank line right
before the ending '"""' Python docstring delimiter.
llvm-svn: 135355
- 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
llvm-svn: 135238
Add a usage example of SBEvent APIs.
o SBEvent.h and SBListener.h:
Add method docstrings for SBEvent.h and SBListener.h, and example usage of SBEvent into
the class docstring of SBEvent.
o lldb.swig:
Add typemap for SBEvent::SBEvent (uint32_t event, const char *cstr, uint32_t cstr_len)
so that we can use, in Python, obj2 = lldb.SBEvent(0, "abc") to create an SBEvent.
llvm-svn: 134766
A few of the auto-generated method docstrings don't look right, and may need to be fixed
by either overwriting the auto-gened docstrings or some post-processing steps.
llvm-svn: 134246
Bruce Mitchener