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
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.
llvm-svn: 128239
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.
llvm-svn: 128053
Currently it has only test cases for SBThread.GetStopDescription() API.
Also modified lldb.swig to add typemap for (char *dst, size_t dst_len)
which occurs for SBThread::GetStopDescription() C++ API. For Python
scripting:
# Due to the typemap magic (see lldb.swig), we pass in an (int)length to GetStopDescription
# and expect to get a Python string as the result object!
# The 100 is just an arbitrary number specifying the buffer size.
stop_description = thread.GetStopDescription(100)
llvm-svn: 127173
the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.
On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.
llvm-svn: 126736
Anytime we had a valid python list that was trying to go from Python down into
our C++ API, it was allocating too little memory and it ended up smashing
whatever was next to the allocated memory.
Added typemap conversions for "void *, size_t" so we can get
SBProcess::ReadMemory() working. Also added a typemap for "const void *, size_t"
so we can get SBProcess::WriteMemory() to work.
Fixed an issue in the DWARF parser where we weren't correctly calculating the
DeclContext for all types and classes. We now should be a lot more accurate.
Fixes include: enums should now be setting their parent decl context correctly.
We saw a lot of examples where enums in classes were not being properly
namespace scoped. Also, classes within classes now get properly scoped.
Fixed the objective C runtime pointer checkers to let "nil" pointers through
since these are accepted by compiled code. We also now don't call "abort()"
when a pointer doesn't validate correctly since this was wreaking havoc on
the process due to the way abort() works. We now just dereference memory
which should give us an exception from which we can easily and reliably
recover.
llvm-svn: 123428
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.
llvm-svn: 123415
ScriptInterpreterPython class and made a simple callback function that
ScriptInterpreterPython::BreakpointCallbackFunction() now calls so we don't
include any internal API stuff into the cpp file that is generated by SWIG.
Fixed a few build warnings in debugserver.
llvm-svn: 115926
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
Temporarily commenting out the deprecated LaunchProcess() method.
SWIG is not able to handle the overloaded functions.
o dotest.py/lldbtest.py:
Add an '-w' option to insert some wait time between consecutive test cases.
o TestClassTypes.py:
Make the breakpoint_creation_by_filespec_python() test method more robust and
more descriptive by printing out a more insightful assert message.
o lldb.swig: Coaches swig to treat StateType as an int type, instead of a C++ class.
llvm-svn: 115899
an auto-generated Python function, and pass the stoppoint context frame and
breakpoint location as parameters to the function (named 'frame' and 'bp_loc'),
to be used inside the breakpoint command Python code, if desired.
llvm-svn: 114849
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
o Fixed a crasher when getting it via SBTarget.GetExecutable().
>>> filespec = target.GetExecutable()
Segmentation fault
o And renamed SBFileSpec::GetFileName() to GetFilename() to be consistent with FileSpec::GetFilename().
llvm-svn: 112308
with the only exception of launching the process from SBTarget which is under
investigation.
o build-swig-Python.sh should also checks the timestamp of ${swig_input_file}
for update eligibility. Also, once an update is in order, there's no need
to check the remaining header files for timestamps.
o Coaches swig to treat StopReason as an int type, instead of a C++ class.
llvm-svn: 112210
Add functions to look up debugger by id
Add global variable to lldb python module, to hold debugger id
Modify embedded Python interpreter to update the global variable with the
id of its current debugger.
Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL)
as a valid value.
The point of all this is so that, when you drop into the embedded interpreter
from the command interpreter (or when doing Python-based breakpoint commands),
there is a way for the Python side to find/get the correct debugger
instance ( by checking debugger_unique_id, then calling
SBDebugger::FindDebuggerWithID on it).
llvm-svn: 107287
Greg Clayton