an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is 
  an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
  should be selected. This helps the native x86 platform on MacOSX select the
  correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
  specific bundles (macosx uses .app bundles that contain files) and also
  selecting the appropriate slice of universal files for a given platform.

So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx

This allows LLDB to be well setup to do remote debugging and also once 
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>

The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.

llvm-svn: 127286

When making a DataExtractor from a Value that's got a ClangType, set the AddressByteSize from the AST Context.

llvm-svn: 126433

The major issue this patch solves is that ArchSpec::SetTriple no longer depends
on the implementation of Host::GetArchitecture.  On linux, Host::GetArchitecture
calls ArchSpec::SetTriple, thus blowing the stack.

A second smaller point is that SetTriple now defaults to Host defined components
iff all OS, vendor and environment fields are not set.

llvm-svn: 126403

of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
  the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple 
  to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
  core we are dealing with into a single enumeration. If you need support for
  a new Core and want to debug it in LLDB, it must be added to this list. In
  the future we can allow for dynamic core registration, but for now it is
  hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
  that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
  with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
  then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
  The mach-o cpu type and subtype can be accessed using the getter functions:
  
  uint32_t
  ArchSpec::GetMachOCPUType () const;

  uint32_t
  ArchSpec::GetMachOCPUSubType () const;
  
  But these functions are just converting out internal llvm::Triple::ArchSpec 
  + ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.

llvm-svn: 126278

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

    clang_type_t
    GetClangFullType(); // Get a completely defined clang type

    clang_type_t
    GetClangLayoutType(); // Get a clang type that can be used for type layout
    
    clang_type_t
    GetClangForwardType(); // A type that can be completed if needed, but is more efficient.
    

llvm-svn: 125691

This patch reverts a portion of r125199 to allow the tree to build again on
linux.  The specific mingw issues that revision intended to address can be
sorted out at a later time.

llvm-svn: 125655

it should live and the lldb_private::Process takes care of managing the 
auto pointer to the dynamic loader instance.

Also, now that the ArchSpec contains the target triple, we are able to 
correctly set the Target architecture in DidLaunch/DidAttach in the subclasses,
and then the lldb_private::Process will find the dynamic loader plug-in 
by letting the dynamic loader plug-ins inspect the arch/triple in the target.

So now the ProcessGDBRemote plug-in is another step closer to be purely 
process/platform agnostic.

I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly.

llvm-svn: 125650

now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
  selection.

llvm-svn: 125602

llvm-svn: 125269

input reader.

Always make sure the input reader stack is not empty before
trying to get the top element from the stack.

llvm-svn: 125255

llvm-svn: 125199

layer a bit more.

llvm-svn: 125149

llvm-svn: 125093

the lldb/source/Host/*.cpp and lldb/source/Host/*/*.cpp directories. The only
offenders are the command completion and the StreamFile.cpp. 

I will soon modify StreamFile.cpp to use a lldb/source/Host/File.cpp so that
all file open, close, read, write, seek, are abstracted into the host layer
as well, then this will be gone.

llvm-svn: 125082

llvm-svn: 125080

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

flags such that symbols can be searched for within a shared library if desired.
Platforms that support the RTLD_FIRST flag can still take advantage of their
quicker lookups, and other platforms can still get the same fucntionality
with a little extra work.

Also changed LLDB_CONFIG flags over to either being defined, or not being
defined to stay in line with current open source practices and to prepare for
using autoconf or cmake to configure LLDB builds.

llvm-svn: 125064

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

llvm-svn: 125031

#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

that aren't always available (sometimes d_namlen or d_reclen). Now strlen is
used to avoid such issues.

llvm-svn: 125008

llvm-svn: 124944

llvm-svn: 124943

llvm-svn: 124931

Patch from Kirk Beitz.

llvm-svn: 124927

llvm-svn: 124897

build issues on MinGW.

llvm-svn: 124888

(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: 124836

llvm-svn: 124810

LLDB plugin directory and a user LLDB plugin directory. We currently still
need to work out at what layer the plug-ins will be, but at least we are 
prepared for plug-ins. Plug-ins will attempt to be loaded from the 
"/Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Plugins" 
folder, and from the "~/Library/Application Support/LLDB/Plugins" folder on
MacOSX. Each plugin will be scanned for:

extern "C" bool LLDBPluginInitialize(void);
extern "C" void LLDBPluginTerminate(void);

If at least LLDBPluginInitialize is found, the plug-in will be loaded. The
LLDBPluginInitialize function returns a bool that indicates if the plug-in
should stay loaded or not (plug-ins might check the current OS, current
hardware, or anything else and determine they don't want to run on the current
host). The plug-in is uniqued by path and added to a static loaded plug-in
map. The plug-in scanning happens during "lldb_private::Initialize()" which
calls to the PluginManager::Initialize() function. Likewise with termination
lldb_private::Terminate() calls PluginManager::Terminate(). The paths for the
plug-in directories is fetched through new Host calls:

    bool Host::GetLLDBPath (ePathTypeLLDBSystemPlugins, dir_spec);
    bool Host::GetLLDBPath (ePathTypeLLDBUserPlugins, dir_spec);

This way linux and other systems can define their own appropriate locations
for plug-ins to be loaded.

To allow dynamic shared library loading, the Host layer has also been modified
to include shared library open, close and get symbol:

    static void *
    Host::DynamicLibraryOpen (const FileSpec &file_spec, 
                              Error &error);

    static Error
    Host::DynamicLibraryClose (void *dynamic_library_handle);

    static void *
    Host::DynamicLibraryGetSymbol (void *dynamic_library_handle, 
                                  const char *symbol_name, 
                                  Error &error);

lldb_private::FileSpec also has been modified to support directory enumeration
in an attempt to abstract the directory enumeration into one spot in the code.
The directory enumertion function is static and takes a callback:


    typedef enum EnumerateDirectoryResult
    {
        eEnumerateDirectoryResultNext,  // Enumerate next entry in the current directory
        eEnumerateDirectoryResultEnter, // Recurse into the current entry if it is a directory or symlink, or next if not
        eEnumerateDirectoryResultExit,  // Exit from the current directory at the current level.
        eEnumerateDirectoryResultQuit   // Stop directory enumerations at any level
    };

    typedef FileSpec::EnumerateDirectoryResult (*EnumerateDirectoryCallbackType) (void *baton,
                                                                                  FileSpec::FileType file_type,
                                                                                  const FileSpec &spec);

    static FileSpec::EnumerateDirectoryResult
    FileSpec::EnumerateDirectory (const char *dir_path,
                                  bool find_directories,
                                  bool find_files,
                                  bool find_other,
                                  EnumerateDirectoryCallbackType callback,
                                  void *callback_baton);

This allow clients to specify the directory to search, and specifies if only
files, directories or other (pipe, symlink, fifo, etc) files will cause the
callback to be called. The callback also gets to return with the action that
should be performed after this directory entry. eEnumerateDirectoryResultNext
specifies to continue enumerating through a directory with the next entry.
eEnumerateDirectoryResultEnter specifies to recurse down into a directory
entry, or if the file is not a directory or symlink/alias to a directory, then
just iterate to the next entry. eEnumerateDirectoryResultExit specifies to 
exit the current directory and skip any entries that might be remaining, yet
continue enumerating to the next entry in the parent directory. And finally
eEnumerateDirectoryResultQuit means to abort all directory enumerations at 
all levels.

Modified the Declaration class to not include column information currently
since we don't have any compilers that currently support column based 
declaration information. Columns support can be re-enabled with the
additions of a #define.

Added the ability to find an EmulateInstruction plug-in given a target triple
and optional plug-in name in the plug-in manager.

Fixed a few cases where opendir/readdir was being used, but yet not closedir
was being used. Soon these will be deprecated in favor of the new directory
enumeration call that was added to the FileSpec class.

llvm-svn: 124716

llvm-svn: 124644

llvm-svn: 124643

source files around into the places they need to go.

llvm-svn: 124631

by name or by pid (with or without waiting for a process to launch) and
catch the response asynchronously.

llvm-svn: 124530