(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

lldb to crash (because of attempt to look for full names when full
names were not used).

llvm-svn: 121607

Various fixes mostly relating to the User Settings stuff:

- Added new utility function to Arg, GetQuotedCommandString, which re-assembles
the args into a string, replacing quotes that were originally there.

- Modified user settings stuff to always show individual elements when printing out
arrays and dictionaries.

- Added more extensive help to 'settings set', explaining more about dictionaries
and arrays (including current dictionary syntax).

- Fixed bug in user settings  where quotes were being stripped and lost, so that
sometimes array or dictionary elements that ought to have been a single element
were being split up.

llvm-svn: 121438

Modify HandleCommand to not do any argument processing until it has determined whether or
not the command should take raw input, then handle & dispatch the arguments appropriately.

Also change the 'alias' command to be a command that takes raw input.  This is necessary to
allow aliases to be created for other commands that take raw input and might want to include
raw input in the alias itself.

Fix a bug in the aliasing mechanism when creating aliases for commands with 3-or-more words.

Raw input should now be properly handled by all the command and alias mechanisms.

llvm-svn: 121423

- Fix alias-building & resolving to properly handle optional arguments for command options.
- Add logging for command resolution ('log enable lldb commands')
- Fix alias resolution to properly handle commands that take raw input (resolve the alias, but
  don't muck up the raw arguments).

Net result:  Among other things, 'expr' command can now take strings with escaped characters and
not have the command handling & alias resolution code muck up the escaped characters. E.g.
 'expr printf ("\n\n\tHello there!")' should now work properly.


Not working yet:  Creating aliases with raw input for commands that take raw input.  Working on that.
e.g. 'command alias print_hi expr printf ("\n\tHi!")' does not work yet.

llvm-svn: 121171

and end-of-file (often control-d).

llvm-svn: 119837

main thread from having to wait on it (which was causing some I/O 
hangs).

llvm-svn: 118700

comes from by using a virtual function to provide it from the Module's
SymbolVendor by default. This allows the DWARF parser, when being used to
parse DWARF in .o files with a parent DWARF + debug map parser, to get its
type list from the DWARF + debug map parser so when we go and find full 
definitions for types (that might come from other .o files), we can use the
type list from the debug map parser. Otherwise we ended up mixing clang types
from one .o file (say a const pointer to a forward declaration "class A") with
the a full type from another .o file. This causes expression parsing, when 
copying the clang types from those parsed by the DWARF parser into the 
expression AST, to fail -- for good reason. Now all types are created in the
same list.

Also added host support for crash description strings that can be set before
doing a piece of work. On MacOSX, this ties in with CrashReporter support
that allows a string to be dispalyed when the app crashes and allows 
LLDB.framework to print a description string in the crash log. Right now this
is hookup up the the CommandInterpreter::HandleCommand() where each command
notes that it is about to be executed, so if we crash while trying to do this
command, we should be able to see the command that caused LLDB to exit. For
all other platforms, this is a nop.

llvm-svn: 118672

Added a top level Timer to the interpreter execute command.  Also added an option to pass the depth to "log timer enable".  That allows you to time just command execution with:

log timer enable 1
<command>
log timer dump

llvm-svn: 118267

keep the file size a bit smaller.

Exposed SBValue::GetExpressionPath() so SBValue users can get an expression
path for their values.

llvm-svn: 117851

version);  change include statements to use Python.h in the Python framework
on Mac OS X systems; leave it using regular Python.h on other systems.

Note:  I think this *ought* to work properly on Linux systems, but I don't have
a system to test it on...

llvm-svn: 117612

sure they come out at the correct times.

llvm-svn: 117470

all of the calls inlined in the header file for better performance.

Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.

Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to 
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.

llvm-svn: 117437

it logs the function calls, their arguments and the return values.  This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done.  It currently does not
attempt to log all the functions, just the most important ones.  I will be 
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).


Update the Python build scripts to re-build the swig C++ file whenever 
the python-extensions.swig file is modified.

Correct the help for 'log enable' command (give it the correct number & type of
arguments).

llvm-svn: 117349

Added "po" alias for "expression -o --"

llvm-svn: 117125

So the issue here was that we have lldb_private::FileSpec that by default was 
always resolving a path when using the:

FileSpec::FileSpec (const char *path);

and in the:

void FileSpec::SetFile(const char *pathname, bool resolve = true);

This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you 
type:

(lldb) breakpoint set --file file.c --line 5

If your current working directory is "/tmp", then "file.c" would be turned 
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.

So I removed the constructor that just takes a path:

FileSpec::FileSpec (const char *path); // REMOVED

You must now use the other constructor that has a "bool resolve" parameter that you must always supply:

FileSpec::FileSpec (const char *path, bool resolve);

I also removed the default parameter to SetFile():

void FileSpec::SetFile(const char *pathname, bool resolve);

And fixed all of the code to use the right settings.

llvm-svn: 116944

argument type, eArgTypeUnixSignal.

llvm-svn: 116764

take raw input).

llvm-svn: 116760

executing properly.

llvm-svn: 116735

the termios settings on the debugger's input handle.

llvm-svn: 116725

    static bool
    Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec);
    
This will fill in "file_spec" with an appropriate path that is appropriate
for the current Host OS. MacOSX will return paths within the LLDB.framework,
and other unixes will return the paths they want. The current PathType
enums are:

typedef enum PathType
{
    ePathTypeLLDBShlibDir,          // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists
    ePathTypeSupportExecutableDir,  // Find LLDB support executable directory (debugserver, etc)
    ePathTypeHeaderDir,             // Find LLDB header file directory
    ePathTypePythonDir              // Find Python modules (PYTHONPATH) directory
} PathType;

All places that were finding executables are and python paths are now updated
to use this Host call.

Added another new host call to launch the inferior in a terminal. This ability
will be very host specific and doesn't need to be supported on all systems.
MacOSX currently will create a new .command file and tell Terminal.app to open
the .command file. It also uses the new "darwin-debug" app which is a small
app that uses posix to exec (no fork) and stop at the entry point of the 
program. The GDB remote plug-in is almost able launch a process and attach to
it, it currently will spawn the process, but it won't attach to it just yet.
This will let LLDB not have to share the terminal with another process and a
new terminal window will pop up when you launch. This won't get hooked up
until we work out all of the kinks. The new Host function is:

    static lldb::pid_t
    Host::LaunchInNewTerminal (
        const char **argv,   // argv[0] is executable
        const char **envp,
        const ArchSpec *arch_spec,
        bool stop_at_entry,
        bool disable_aslr);

Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero 
filling the entire path buffer.

Fixed an issue with the dynamic checker function where I missed a '$' prefix
that should have been added.

llvm-svn: 116690

and 'process handle'.  The test suite would like to control the asynch/sync
execution of the interpreter during the middle of the test method, so the
CommandInterpreter::SetSynchronous(bool value) is modified to allow the mode to
be changed more than once.

In practice, it would be advisable to control the process and to set the
async/sync mode from a single thread, too.

llvm-svn: 116467