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
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
llvm-svn: 184500
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
@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
//------------------------------------------------------------------
/// Get all types matching \a type_mask from debug info in this
/// module.
///
/// @param[in] type_mask
/// A bitfield that consists of one or more bits logically OR'ed
/// together from the lldb::TypeClass enumeration. This allows
/// you to request only structure types, or only class, struct
/// and union types. Passing in lldb::eTypeClassAny will return
/// all types found in the debug information for this module.
///
/// @return
/// A list of types in this module that match \a type_mask
//------------------------------------------------------------------
lldb::SBTypeList
SBModule::GetTypes (uint32_t type_mask)
//------------------------------------------------------------------
/// Get all types matching \a type_mask from debug info in this
/// compile unit.
///
/// @param[in] type_mask
/// A bitfield that consists of one or more bits logically OR'ed
/// together from the lldb::TypeClass enumeration. This allows
/// you to request only structure types, or only class, struct
/// and union types. Passing in lldb::eTypeClassAny will return
/// all types found in the debug information for this compile
/// unit.
///
/// @return
/// A list of types in this compile unit that match \a type_mask
//------------------------------------------------------------------
lldb::SBTypeList
SBCompileUnit::GetTypes (uint32_t type_mask = lldb::eTypeClassAny);
This lets you request types by filling out a mask that contains one or more bits from the lldb::TypeClass enumerations, so you can only get the types you really want.
llvm-svn: 184251
- exposing new accessors: formats/format, ..., that allow you to iterate over all formatters
e.g. sys_category = lldb.debugger.GetCategory("system").summary['char *']
- ensuring that C++-based synthetic children provider can at least print their description accurately, if nothing else
llvm-svn: 183805
Providing a Python helper SBData.CreateDataFromInt() to make an SBData out of a single integer number
It tries to use the current target, if any, for endianness and pointer size, and it picks a reasonable size on your behalf - if there is no way it can infer anything reasonable it essentially picks a 64-bit Mac as the reference model
llvm-svn: 183793
Allowing LLDB to resolve names of Python functions when they are located in classes
This allows things like *bound* classmethods to be used for formatters, commands, ...
llvm-svn: 183772
Upon encountering an object not of type string, LLDB will get the string representation of it (akin to calling str(X) in Python code) and use that as the summary to display
Feedback is welcome as to whether repr() should be used instead (but the argument for repr() better be highly persuasive :-)
llvm-svn: 182953
- copy lldb python module into directory specified with CMAKE_INSTALL_PREFIX
- make liblldb.so a symlink (to liblldb.so.X.Y where X.Y is the LLVM version)
llvm-svn: 182157
Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated
Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing:
a) the SWIG wrapper was not checking the return value of the script
b) when passing a Python function by name, the call statement was dropping the return value of the function
This checkin addresses both concerns and makes this work
Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop!
llvm-svn: 181866
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
finish-swig-Python-LLDB.sh to create a new lldb.diagnose subdirectory
in the LLDB framework; the first diagnostic command in this directory
is diagnose-unwind. There may be others added in the future.
Users can load these diagnostic tools into their session with
"script import lldb.diagnose".
llvm-svn: 180768
Two reasons for that:
* the declaration is not used. the LLDB_SOURCE_DIR is provided as the first argument in the script ($1) (called SRC_ROOT in the source code)
* add_custom_command is quoting the first argument of the command. Usually, it is the script itself (and then the full path to the script) but, here, it is the declaration of a variable.
It was failing with:
cd "/llvm-toolchain-3.3~svn179457/build-llvm/tools/lldb/scripts" && "SRCROOT=/llvm-toolchain-3.3~svn179457/tools/lldb" /llvm-toolchain-3.3~svn179457/tools/lldb/scripts/build-swig-wrapper-classes.sh /llvm-toolchain-3.3~svn179457/tools/lldb /llvm-toolchain-3.3~svn179457/build-llvm/tools/lldb/scripts /llvm-toolchain-3.3~svn179457/build-llvm/tools/lldb/scripts /llvm-toolchain-3.3~svn179457/build-llvm -m
/bin/sh: 1: SRCROOT=/llvm-toolchain-3.3~svn179457/tools/lldb: not found
llvm-svn: 179459
Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache()
This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them.
In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols).
Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added.
Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic.
llvm-svn: 178897
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
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
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
"compile_units" returns an array of all compile units in a module as a list() of lldb.SBCompileUnit objects.
"compile_unit" returns a compile unit accessor object that allows indexed access, search by full or partial path, or by regex:
(lldb) script
comp_unit = lldb.target.module['TextEdit'].compile_unit['Document.m']
comp_unit = lldb.target.module['TextEdit'].compile_unit['/path/to/Document.m']
comp_unit = lldb.target.module['TextEdit'].compile_unit[0]
comp_unit = lldb.target.module['TextEdit'].compile_unit[1]
for comp_unit in lldb.target.module['TextEdit'].compile_unit[re.compile("\.m$")]
print comp_unit
This helps do quick searches and scripting while debugging.
llvm-svn: 176613
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.
<rdar://problem/11319574>
<rdar://problem/9329275>
llvm-svn: 176392
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug
session.
<rdar://problem/12993641>
llvm-svn: 174793
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.
llvm-svn: 173463
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.
llvm-svn: 172873
Adding FindFirstGlobalVariable to SBModule and SBTarget
These calls work like FindGlobalVariables but they only return the first match found and so they can return an SBValue instead of an SBValueList for added convenience of use
llvm-svn: 172636
Added a unique integer identifier to processes. Some systems, like JTAG or other simulators, might always assign the same process ID (pid) to the processes that are being debugged. In order for scripts and the APIs to uniquely identify the processes, there needs to be another ID. Now the SBProcess class has:
uint32_t SBProcess::GetUniqueID();
This integer ID will help to truly uniquely identify a process and help with appropriate caching that can be associated with a SBProcess object.
llvm-svn: 172628
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.
<rdar://problem/12986644>
<rdar://problem/9119325>
llvm-svn: 172503
As with llvm svn r172138, this patch is basically copying some changes that
we've been using for building clang at Apple. Besides cleaning it up to use
xcrun to locate the proper versions of tools, especially for cross compiling,
it fixes the build to work with newer versions of clang that honor SDKROOT
settings in the environment.
llvm-svn: 172324
This script used an inconsistent mix of spaces and tabs, and even
ignoring that, it still had inconsistent indentation, which is
pretty scary for a Python script. I also removed trailing whitespace
from some lines.
llvm-svn: 172237
Added SBTarget::EvaluateExpression() so expressions can be evaluated without needing a process.
Also fixed many functions that deal with clang AST types to be able to properly handle the clang::Type::Elaborated types ("struct foo", "class bar").
llvm-svn: 171476
Added a "step-in-target" flag to "thread step-in" so if you have something like:
Process 28464 stopped
* thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1
frame #0: 0x0000000100000e08 a.out`main at main.c:62
61
-> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint.
63
and you want to get into "complex" skipping a, b and c, you can do:
(lldb) step -t complex
Process 28464 stopped
* thread #1: tid = 0x1c03, function: complex , stop reason = step in
frame #0: 0x0000000100000d0d a.out`complex at main.c:44
41
42 int complex (int first, int second, int third)
43 {
-> 44 return first + second + third; // Step in targetting complex should stop here
45 }
46
47 int main (int argc, char const *argv[])
llvm-svn: 170008
lldb.target
lldb.process
lldb.thread
lldb.frame
are initialized to at least contain empty lldb classes in case some python gets imported that uses them.
llvm-svn: 169750
Add the ability to get a symbol or symbols by name and type from a SBModule, and also the ability to get all symbols by name and type from SBTarget objects.
llvm-svn: 169205
There should be no functional changes as SBData creation functions already checked for NULL regardless of size - but it ensures consistency
llvm-svn: 166978
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
llvm-svn: 166495
Added a new API call to help efficiently determine if a SBValue could have children:
bool
SBValue::MightHaveChildren ();
This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive.
llvm-svn: 166460
Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
no trivial way for us to change the SP inside an SBValue on the fly
This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)
llvm-svn: 166426
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
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
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface
There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.
Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command
For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands
Caveats:
Currently, the new API objects and features are not exposed via Python.
The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own
llvm-svn: 164865
which builds a Debug+Asserts build of Clang and
links LLDB against it. The Debug configuration
builds Clang with Release+Asserts, for faster
linking and smaller memory footprint when debugging
the build LLDB.
llvm-svn: 164573
Enrico Granata