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

then we end up using older .o files with out of date section remappings if
we debug, compile + fix, and debug again.

llvm-svn: 127166

It will just load all files exactly where the files state they are (file
addresses == load addresses). This is used when the llvm::Triple::OSType is
set to llvm::Triple::UnknownOS or llvm::Triple::NoOS.

llvm-svn: 127053

chosing which FP back-chain methods to use since we can rely upon generic 
register numbers after that.

llvm-svn: 127044

Add code to emulate RFE Arm instruction.

Add new instruction context for RFE instruction.

Add several new helper functions to help emulate RFE instruction
(including CurrentModeIsPrivileged, BadMode, and CPSRWriteByInstr).

llvm-svn: 126965

Add code to emulate UXTH Arm instruction.

llvm-svn: 126954

Add code to emulate UXTB Arm instruction.

llvm-svn: 126953

Add code to emulate SXTH Arm instruction.

llvm-svn: 126951

Add code to emulate SXTB Arm instruction.

llvm-svn: 126949

Fix bug where bitwise-AND was being used and it should have been bitwise-OR.

llvm-svn: 126904

Add code to emulate ADD (immediate, Thumb) Arm instruction.

Add addition context to EmulateInstruction contexts.

llvm-svn: 126903

Add code to emulate MUL Arm instruction.

Add new context type & info structure for  mul instruction.

llvm-svn: 126891

anything in a SBSymbolContext filled in given an SBAddress:

SBSymbolContext
SBTarget::ResolveSymbolContextForAddress (const SBAddress& addr, uint32_t resolve_scope);

Also did a little cleanup on the ProcessGDBRemote stdio file handle
code.

llvm-svn: 126885

Add code to emulate LDRSH (register) Arm instruction.

llvm-svn: 126881

Add code to emulate LDRSH (literal) Arm instruction.

llvm-svn: 126866

Add code to emulate LDRSH (immediate) Arm instruction.

llvm-svn: 126807

Add code to emulate LDRSB (register) Arm instruction.

llvm-svn: 126802

Add code to emulate LDRSB (literal) Arm instruction.

llvm-svn: 126789

Add code to emulate LDRSB (immediate) Arm instruction.

llvm-svn: 126783

Add code to emulate LDRH (register) Arm instruction.

llvm-svn: 126758

Add code to emulate LDRH (literal) Arm instruction.

llvm-svn: 126709

Add register context for i386 on Linux.

Patch by Marco Minutoli!

llvm-svn: 126696

Add code to emulate LDRH (immediate, Thumb) arm instruction.

llvm-svn: 126692

llvm-svn: 126456

Modifed lldb_private::Process to be able to handle connecting to a remote 
target that isn't running a process. This leaves lldb_private::Process in the
eStateConnected state from which we can then do an attach or launch.

Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working
dir, disable ASLR and a few other settings down by using new GDB remote 
packets. This allows us to keep all of our current launch flags and settings
intact and still be able to communicate them over to the remote GDB server.
Previously these were being sent as arguments to the debugserver binary that
we were spawning. Also modified ProcessGDBRemote to handle losing connection
to the remote GDB server and always exit immediately. We do this by watching
the lldb_private::Communication event bit for the read thread exiting in the
ProcessGDBRemote async thread.

Added support for many of the new 'Q' packets for setting stdin, stdout,
stderr, working dir and disable ASLR to the GDBRemoteCommunication class for
easy accesss.

Modified debugserver for all of the new 'Q' packets and also made it so that
debugserver always exists if it loses connection with the remote debugger.

llvm-svn: 126444

llvm-svn: 126442

switch to Jazelle state fails, thus treating BXJ as a BX operation.

llvm-svn: 126423

llvm-svn: 126406

Also fix a bug where we were not lazily parsing the ELF header and thus
returning an ArchSpec with invalid cpu type components.  Initialize the cpu
subtype as LLDB_INVALID_CPUTYPE for compatibility with the new ArchSpec
implementation.

llvm-svn: 126405

llvm-svn: 126355

llvm-svn: 126343

and rename the original ThumbImmScaled() function to ThumbImm7Scaled().

llvm-svn: 126335

Rd == 13.  Add opcode entries for the generic "sub (sp minus immediate)" operations.

llvm-svn: 126293

llvm-svn: 126283

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