bool
     SBType::IsFunctionType ();

     lldb::SBType
     SBType::GetFunctionReturnType ();
 
     lldb::SBTypeList
     SBType::GetFunctionArgumentTypes ();

llvm-svn: 167023

There should be no functional changes as SBData creation functions already checked for NULL regardless of size - but it ensures consistency

llvm-svn: 166978

llvm-svn: 166799

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

llvm-svn: 166070

the SB API's that evaluate expressions.

<rdar://problem/12457211>

llvm-svn: 166062

llvm-svn: 166060

<rdar://problem/12446320> Fixing an issue with our Driver where setting an immediate output would not cause suppression of the final printout. This allows effective output redirection for Python commands

llvm-svn: 166058

From SBType, we can now get a lldb::BasicType enumeration out of an existing type.

llvm-svn: 165857

SBProcess::SetSelectedThreadByID() had a "uint32_t tid" parameter which would truncate 64 bit thread IDs (lldb::tid_t is 64 bit).

llvm-svn: 165852

<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

Change the Thread constructor over to take a Process& rather than a ProcessSP.  We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
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

llvm-svn: 165460

<rdar://problem/12200505> Fixing a logical error in SBProcess, where the get_process_thread_list function was creating invalid threads_access instances, and hence failing to correctly fill in the list

llvm-svn: 165421

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

llvm-svn: 165410

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

llvm-svn: 165348

llvm-svn: 165344

llvm-svn: 165328

<rdar://problem/12099999> renaming SBStream::Printf to Print in the scripting world in order to avoid supporting varargs through SWIG

llvm-svn: 165274

from LLVM and Clang.  This made "svn update" very
unpleasant if the original repository was fetched by
build-llvm.pl.

llvm-svn: 165268

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

llvm-svn: 164801

llvm-svn: 164648

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

top-of-tree.  Removed all local patches and llvm.zip.

The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur.  Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.

llvm-svn: 164563

llvm-svn: 164227

This may (but shouldn't) break Linux (but I tested and it still worked on FreeBSD).

The same shell scripts are now used on Xcode and Makefiles, for generating
the SWIG bindings.
Some compatibility fixes were applied, too (python path, bash-isms, etc).

llvm-svn: 163912

llvm-svn: 163867

llvm-svn: 163725

llvm-svn: 163670

llvm-svn: 163250

./verify_api.py --library ./LLDB.framework/LLDB --api-regex lldb --arch x86_64 /Applications/Xcode.app/Contents/PlugIns/DebuggerLLDB.ideplugin/Contents/MacOS/DebuggerLLDB

So you specify a library with the "--library" option, then you specify an API regular expression that you want to match the executables against with "--api-regex <regex>", here we specify "lldb" to catch all undefined external API functions from the binary we want to test, then we specify the architectures to check with "--arch <arch>" (this can be specified more than once), and you give one or more executables.

llvm-svn: 162941

llvm-svn: 162753

llvm-svn: 162685

- 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

llvm-svn: 162527