Add a few missing virtual methods to PlatformLinux and have it register itself
with PluginManager.

llvm-svn: 128128

platform connect <args>
platform disconnect

Each platform can decide the args they want to use for "platform connect". I 
will need to add a function that gets the connect options for the current
platform as each one can have different options and argument counts.

Hooked up more functionality in the PlatformMacOSX and PlatformRemoteiOS.
Also started an platform agnostic PlatformRemoteGDBServer.cpp which can end
up being used by one or more actual platforms. It can also be specialized and
allow for platform specific commands.

llvm-svn: 128123

More fixes for ARM instruction emulation code:
  - Remove duplicate write from EmulateLDRRtPCRelative.
  - Add a missing encoding to EmulateADDSPImm.
  - Fix minor problems in Thumb instruction tables.

llvm-svn: 128115

GDBRemoteCommunication - The base GDB remote communication class
GDBRemoteCommunicationClient - designed to be used for clients the connect to
                               a remote GDB server
GDBRemoteCommunicationServer - designed to be used on the server side of a
                               GDB server implementation.

llvm-svn: 128070

llvm-svn: 128066

Clean up a few places where SetOptionValue was using the global optarg, rather than the option_arg value that was passed in.

llvm-svn: 128064

Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function.
Also added a "-p" flag that disassembles from the current pc.

llvm-svn: 128063

llvm-svn: 128062

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

process ID to the ProcessInfo.

llvm-svn: 128023

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

Fix various small problems with EmulateInstructionARM::EmulateSTRRtSP.

llvm-svn: 127898

ObjC runtime for print object to Pointer AND Integer (from just pointer.)

llvm-svn: 127841

Make all the codee that attempts to read the PC consistently use
ReadCoreReg (which 'does the right thing', adding to pc when needed);
fixed places in code where extra addition was being passed along.

Fix bug in insn tables.

llvm-svn: 127838

Fix a problem where we were looking up the class pointer in the {class/sel -> implementation} cache for a objc_msgSendSuper call - where we should have looked up the class's super-class.

llvm-svn: 127830

llvm-svn: 127825

Add code to emulate STRH (Register) Arm instruction.

Remove inaccurate comments from EmulateInstruction::Context definition.

Fix contexts in a few arm instruction emulation routines.

llvm-svn: 127770

Fix various small bugs found in the instruction emulation functions.

llvm-svn: 127712

for templatized types that could cause parts of a std::vector (and I am sure
other STL types) to be incorrectly uniqued to each other wreaking havoc on 
variable display for types within the same executable module.

llvm-svn: 127662

llvm-svn: 127659

llvm-svn: 127634

This change is needed to fix the build on Linux. 

llvm-svn: 127557

Add a first pass at a "stop hook" mechanism.  This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc.  You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file.

Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language.

llvm-svn: 127457

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: 127450

llvm-svn: 127439

Add some explanatory comments.

llvm-svn: 127438

so that it actually triggers raw output.

llvm-svn: 127433

The UserSettings controllers must be initialized & terminated in the
correct order.  Previously this was tacitly implemented but not
enforced, so it was possible to accidentally do things in the wrong
order and cause problems.  This fixes that problem.

llvm-svn: 127430

This patch supports building the Linux platform plugin, and should also support
the MacOSX plugin as well (the MacOSX side has not been tested, unfortunately).
A small typo was corrected in lldb.cpp to initialize the new platform code on
Linux.

llvm-svn: 127393

member variable (m_packet_timeout which is a value in seconds). This value is
then used for all packets sent to/from the remote GDB server.

llvm-svn: 127392

ARM disassembler was wrong, causing the disassembler to fail
to initialize.

llvm-svn: 127302

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

ELF object files do not implicitly have a symbol named "start" as an entry
point.  For example, on Linux it is often named "_start", but can be trivially
set to any symbol by passing an --entry argument to the linker.

Use the ELF header to determine the entry point and resolve the associated
section based on that address.

Also, update the linux dynamic loader to call GetEntryPointAddress instead of
GetEntryPoint.

llvm-svn: 127218

llvm-svn: 127215

I didn't notice there was already an ObjectFile::GetEntryPoint.  Move that over to GetEntryPointAddress 'cause that's more consistent with other functions in ObjectFile, do the mutatis mutandi and also in the ELF case I return a section offset address rather than a bare load address.

llvm-svn: 127205

Reverting the part of the debug-in-ofile patch from earlier today that removes them from the shared module list.  That was causing a bunch of asserts.  Greg is working on a better fix.

llvm-svn: 127201

Add a method "GetEntryPoint" to the ObjectFile class, and implement it on MachO & ELF - though the ELF implementation is probably a little weak.  Then use this method in place of directly looking for "start" in the ThreadPlanCallFunction constructor to find the stopping point for our function evaluation.

llvm-svn: 127194