(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

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

argument type, eArgTypeUnixSignal.

llvm-svn: 116764

Add missing break statment to case statement in Process::ShouldBroadcastEvent.

Add new command, "process handle" to allow users to control process behavior on
the receipt of various Unix signals (whether the process should stop; whether the
process should be passed the signal; whether the debugger user should be notified
that the signal came in).

llvm-svn: 116430

llvm-svn: 116351

obey the UnixSignals table that we have in the process.

llvm-svn: 116139

llvm-svn: 116114

Fixed a crasher when doing 'help image dump symtab'.  Supply the entry to the global arguments table.

llvm-svn: 116058

(for standardized argument names, argument help, etc.)

llvm-svn: 115570

Modify command options to use the new arguments mechanism.  Now all command option
arguments are specified in a standardized way, will have a standardized name, and
have functioning help.

The next step is to start writing useful help for all the argument types.

llvm-svn: 115335

Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.

Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism.  Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).

Help command now works for all argument types, although the help may not
be very helpful yet.

Those commands that take "raw" command strings now indicate it in their
help text.

llvm-svn: 115318

accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.

While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.

Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").

llvm-svn: 114252

Make get/set variable at the debugger level always set the particular debugger's instance variables rather than
the default variables.

llvm-svn: 113474

interface so everybody does it the same way.  Add an "exact" lookup for internal uses.

Fix up a few little cases where we weren't reporting command lookup errors correctly.

Added "b" as an alias for "breakpoint" so it doesn't collide with "bt".

llvm-svn: 107718

Add a way for the completers to say whether the completed argument should have a space inserted after is
or not.
Added the file name completer to the "file" command.

llvm-svn: 107247

llvm-svn: 106784

to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.

To avoid this we now create instances of the lldb_private::Debugger that each 
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack

So now clients should call:

    SBDebugger::Initialize(); // (static function)

    SBDebugger debugger (SBDebugger::Create());
    // Use which ever file handles you wish
    debugger.SetErrorFileHandle (stderr, false);
    debugger.SetOutputFileHandle (stdout, false);
    debugger.SetInputFileHandle (stdin, true);

    // main loop
    
    SBDebugger::Terminate(); // (static function)
    
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.

Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.

llvm-svn: 106615

llvm-svn: 106034

llvm-svn: 105619