standard output, resolving a crasher.

llvm-svn: 106682

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

the demangled name. Fall back to strlen.

llvm-svn: 106579

This also moves strlen out of the mutex scope.

llvm-svn: 106545

I'm not sure when multiple threads enter this method but a race-condition
causing a crash in malloc can be reproduced with this little script:

echo file $(which lldb) > cmd
echo "run\nbreak set -n main\nrun\nexit" >> cmd
lldb -s cmd

It may need a few runs before it crashes though.

llvm-svn: 106544

llvm-svn: 106535

instructions so it's really profitable to inline them.

llvm-svn: 106450

dependent on the last byte of the buffer, which could be unitialized.

llvm-svn: 106417

This also fixes a bug where we were trying to copy m_string into itself
via a format string. The pointer was invalidated by m_string.resize and
lldb (sometimes) crashed inside vsnprintf.

llvm-svn: 106416

llvm-svn: 106034

Fixed the Disassemble arguments so you can't specify start address or name in multiple ways.
Fixed the command line input so you can specify the filename without "-f" even if you use other options.

llvm-svn: 106020

llvm-svn: 105922

llvm-svn: 105866

Fixed problem Jean-Daniel Dupas found in ProcessGDBRemote.cpp.

llvm-svn: 105857

llvm-svn: 105813

llvm-svn: 105811

llvm-svn: 105810

type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single arch definition that the LLDB
core code can use. Previously a lot of places in the code were using the
mach-o definitions from a macosx header file. 

Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the
CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so 
we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs.

Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being
used in LLDB.

llvm-svn: 105806

llvm-svn: 105799

llvm-svn: 105798

llvm-svn: 105780

Google C++ coding guidelines where includes are done as:

1 - the header file for the current source file
2 - C includes
3 - C++ includes
4 - external project includes
5 - current project includes

llvm-svn: 105748

llvm-svn: 105736

llvm-svn: 105724

llvm-svn: 105723

llvm-svn: 105721

llvm-svn: 105712

llvm-svn: 105619