llvm-svn: 128136

llvm-svn: 128066

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

static archive that can be linked against. LLDB.framework/lldb.so
exports a very controlled API. Splitting the API into a static
library allows other tools (debugserver for now) to use the power
of the LLDB debugger core, yet not export it as its API is not
portable or maintainable. The Host layer and many of the other
internal only APIs can now be statically linked against.

Now LLDB.framework/lldb.so links against "liblldb-core.a" instead
of compiling the .o files only for the shared library. This fix
is only for compiling with Xcode as the Makefile based build already
does this.

The Xcode projecdt compiler has been changed to LLVM. Anyone using
Xcode 3 will need to manually change the compiler back to GCC 4.2,
or update to Xcode 4.

llvm-svn: 127963

platform status -- gets status information for the selected platform
platform create <platform-name> -- creates a new instance of a remote platform
platform list -- list all available platforms
platform select -- select a platform instance as the current platform (not working yet)

When using "platform create" it will create a remote platform and make it the
selected platform. For instances for iPhone OS debugging on Mac OS X one can 
do:

(lldb) platform create remote-ios --sdk-version=4.0
Remote platform: iOS platform
SDK version: 4.0
SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0"
Not connected to a remote device.
(lldb) file ~/Documents/a.out
Current executable set to '~/Documents/a.out' (armv6).
(lldb) image list
[  0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[  1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld
[  2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib


Note that this is all happening prior to running _or_ connecting to a remote
platform. Once connected to a remote platform the OS version might change which
means we will need to update our dependecies. Also once we run, we will need
to match up the actualy binaries with the actualy UUID's to files in the
SDK, or download and cache them locally.

This is just the start of the remote platforms, but this modification is the
first iteration in getting the platforms really doing something.

llvm-svn: 127934

CommandInterpreter::HandleCommands should take its commands as a "const StringList &" since it doesn't modify it...

Also, don't turn on the immediate output in the temporary result, or you'll get doubled output.

llvm-svn: 127452

llvm-svn: 127451

llvm-svn: 127439

Add some explanatory comments.

llvm-svn: 127438

Add thread state initialization to the thread where the interactive
interpreter is run (which is separate from the thread where
Py_Initialize is called, where this normally gets set up).

llvm-svn: 127191

N streams by making the stream a vector of stream shared pointers
that is protected by a mutex. Streams can be get/set by index which
allows indexes to be defined as stream indentifiers. If a stream is
set at index 3 and there are now streams in the collection, then
empty stream objects are inserted to ensure that stream at index 3
has a valid stream. There is also an append method that allows a stream
to be pushed onto the stack. This will allow our streams to be very
flexible in where the output goes.

Modified the CommandReturnObject to use the new StreamTee functionality.
This class now defines two StreamTee indexes: 0 for the stream string
stream, and 1 for the immediate stream. This is used both on the output
and error streams.

Added the ability to get argument types as strings or as descriptions.
This is exported through the SBCommandInterpreter API to allow external
access.

Modified the Driver class to use the newly exported argument names from
SBCommandInterpreter::GetArgumentTypeAsCString().

llvm-svn: 126067

a Stream, and then added GetOutputData & GetErrorData to get the accumulated data.
- Added a StreamTee that will tee output to two provided lldb::StreamSP's.
- Made the CommandObjectReturn use this so you can Tee the results immediately to
the debuggers output file, as well as saving up the results to return when the command
is done executing.
- HandleCommands now uses this so that if you have a set of commands that continue the target
you will see the commands come out as they are processed.
- The Driver now uses this to output the command results as you go, which makes the interface
more reactive seeming.

llvm-svn: 126015

Targets can now specify some additional parameters for when we debug 
executables that can help with plug-in selection:

target.execution-level = auto | user | kernel
target.execution-mode  = auto | dynamic | static
target.execution-os-type = auto | none | halted | live

On some systems, the binaries that are created are the same wether you use
them to debug a kernel, or a user space program. Many times inspecting an 
object file can reveal what an executable should be. For these cases we can
now be a little more complete by specifying wether to detect all of these
things automatically (inspect the main executable file and select a plug-in
accordingly), or manually to force the selection of certain plug-ins.

To do this we now allow the specficifation of wether one is debugging a user
space program (target.execution-level = user) or a kernel program 
(target.execution-level = kernel).

We can also specify if we want to debug a program where shared libraries
are dynamically loaded using a DynamicLoader plug-in 
(target.execution-mode = dynamic), or wether we will treat all symbol files
as already linked at the correct address (target.execution-mode = static).

We can also specify if the inferior we are debugging is being debugged on 
a bare board (target.execution-os-type = none), or debugging an OS where
we have a JTAG or other direct connection to the inferior stops the entire
OS (target.execution-os-type = halted), or if we are debugging a program on
something that has live debug services (target.execution-os-type = live).

For the "target.execution-os-type = halted" mode, we will need to create 
ProcessHelper plug-ins that allow us to extract the process/thread and other
OS information by reading/writing memory.

This should allow LLDB to be used for a wide variety of debugging tasks and
handle them all correctly.

llvm-svn: 125815

Factor all the code that does "Execute a list of lldb command interpreter commands" into a single function in the Interpreter, and then use that in all the places that used to do this by hand.

llvm-svn: 125807

layer a bit more.

llvm-svn: 125149

We have a common unix implementation in lldb/source/Host/common/FileSpec.cpp.

llvm-svn: 125078

integer. Modified patch from Kirk Beitz.

llvm-svn: 125067

where the implementation is hidden in the host layer. This avoids
a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the
code and keeps things cleaner.

llvm-svn: 125057

#include "lldb/Host/Config.h"

Or the LLDB_CONFIG_TERMIOS_SUPPORTED defined won't be set. I will fix all
of this Termios stuff later today by moving lldb/Core/TTYState.* into the 
host layer and then we conditionalize all of this inside TTYState.cpp and
then we get rid of LLDB_CONFIG_TERMIOS_SUPPORTED all together.

Typically, when we start to see too many "#if LLDB_CONFIG_XXXX" preprocessor
directives, this is a good indicator that something needs to be moved over to
the host layer. TTYState can be modified to do all of the things that many
areas of the code are currently doing, and it will avoid all of the 
preprocessor noise.

llvm-svn: 125027

llvm-svn: 125024

llvm-svn: 124931

(lldb) process connect <remote-url>

Currently when you specify a file with the file command it helps us to find
a process plug-in that is suitable for debugging. If you specify a file you
can rely upon this to find the correct debugger plug-in:

% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) process connect connect://localhost:2345
...

If you don't specify a file, you will need to specify the plug-in name that
you wish to use:

% lldb
(lldb) process connect --plugin process.gdb-remote connect://localhost:2345

Other connection URL examples:

(lldb) process connect connect://localhost:2345
(lldb) process connect tcp://127.0.0.1
(lldb) process connect file:///dev/ttyS1

We are currently treating the "connect://host:port" as a way to do raw socket
connections. If there is a URL for this already, please let me know and we
will adopt it.

So now you can connect to a remote debug server with the ProcessGDBRemote
plug-in. After connection, it will ask for the pid info using the "qC" packet
and if it responds with a valid process ID, it will be equivalent to attaching.
If it response with an error or invalid process ID, the LLDB process will be
in a new state: eStateConnected. This allows us to then download a program or
specify the program to run (using the 'A' packet), or specify a process to
attach to (using the "vAttach" packets), or query info about the processes
that might be available.

llvm-svn: 124846

llvm-svn: 124811

(<rdar://problem/8946573>)

llvm-svn: 124711

llvm-svn: 124643

extra launch options:

LLDB_LAUNCH_FLAG_DISABLE_ASLR disables ASLR for all launched processes

LLDB_LAUNCH_FLAG_DISABLE_STDIO will disable STDIO (reroute to "/dev/null")
for all launched processes

LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY will force all launched processes to be
launched in new terminal windows.

Also, don't init python if we never create a script interpreter.

llvm-svn: 124341

llvm-svn: 124250

allowing timeouts & informing the user when the lock is unavailable.


Fixed problem where Debugger::Terminate was clearing the debugger list
even when the global ref count was greater than zero.

llvm-svn: 123674

the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a 
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.

A few months ago I worked with the llvm/clang folks to have the 
ExternalASTSource class be able to complete classes if there weren't completed
yet:

class ExternalASTSource {
....

    virtual void
    CompleteType (clang::TagDecl *Tag);
    
    virtual void 
    CompleteType (clang::ObjCInterfaceDecl *Class);
};

This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.

This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
  objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
  types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
  ClangASTType, and more) can now be iterating through children of any type,
  and if a class/union/struct type (clang::RecordType or ObjC interface) 
  is found that is incomplete, we can ask the AST to get the definition. 
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
  all child SymbolFileDWARF classes will share (much like what happens when
  we have a complete linked DWARF for an executable).
  
We will need to modify some of the ClangUserExpression code to take more 
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.

llvm-svn: 123613

when handling one-liner commands that contain escaped characters.  In
order to deal with the new namespace/dictionary stuff, the command was
being embedded within a second string, which messed up the escaping.

This fixes the problem by handling one-liners in a different manner, so they
no longer need to be embedded within another string, and can still be
processed in the proper namespace/dictionary context.

llvm-svn: 123467

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

Thanks Bruce!

llvm-svn: 123083

test case test_help_version().

llvm-svn: 122515

llvm-svn: 122198

a shell would interpret it. A few examples that we now handle correctly

INPUT: "Hello "world
OUTPUT: "Hello World"

INPUT: "Hello "' World'
OUTPUT: "Hello World"

INPUT: Hello" World"
OUTPUT: "Hello World"

This broke the setting of dictionary values for the "settings set" command
for things like:

(lldb) settings set target.process.env-vars ["MY_ENV_VAR"]=YES

since we would drop the quotes. I fixed the user settings controller to use
a regular expression so it can accept any of the following inputs for
dictionary setting:

settings set target.process.env-vars ["MY_ENV_VAR"]=YES
settings set target.process.env-vars [MY_ENV_VAR]=YES
settings set target.process.env-vars MY_ENV_VAR=YES

We might want to eventually drop the first two syntaxes, but I won't make
that decision right now.

This allows more natural setting of the envirorment variables:

settings set target.process.env-vars MY_ENV_VAR=YES ABC=DEF CWD=/tmp

llvm-svn: 122166

   Extend Swig's include search path.

   Cover both /usr/include and /usr/local/include.  This should allow Swig to find
   system headers such as stdint.h on all platforms we currently support.

llvm-svn: 121943

Pass the test suite on Mac OS X Snow Leopard.

llvm-svn: 121924

llvm-svn: 121884

llvm-svn: 121785

Fix small bugs:

- Make sure cmd_obj & cmd_obj_sp contain a valid objects before attempting to 
dereference, in CommandObjectCommandsAlias::Execute and 
CommandInterpreter::HandleCommand.

- Modify CommandInterpreter::GetCommandSPExact to properly handle
multi-word command inputs.

llvm-svn: 121779