Add code to emulate LDRSH (immediate) Arm instruction.

llvm-svn: 126807

Add code to emulate LDRSB (register) Arm instruction.

llvm-svn: 126802

among other SBProcess APIs, to write (int)256 into a memory location of a global variable
(int)my_int and reads/checks the variable afterwards.

llvm-svn: 126792

Add code to emulate LDRSB (literal) Arm instruction.

llvm-svn: 126789

Add code to emulate LDRSB (immediate) Arm instruction.

llvm-svn: 126783

llvm-svn: 126774

This makes the number of total tests equal to 201.

llvm-svn: 126769

Add code to emulate LDRH (register) Arm instruction.

llvm-svn: 126758

the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.

On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.

llvm-svn: 126736

llvm-svn: 126732

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

otherwise, use the thing the debugserver is started with.

Fixed rdar://problem/9056462
The process launch flag '-w' for setting the current working directory not working?

llvm-svn: 126537

llvm-svn: 126531

the intermediate files built with the same dictionary during test execution.

llvm-svn: 126530

current working directory when running the inferior.  Radar filed:

    # rdar://problem/9056462
    # The process launch flag '-w' for setting the current working directory not working?

llvm-svn: 126529

llvm-svn: 126517

llvm-svn: 126516

llvm-svn: 126515

related to 'process launch' command.

llvm-svn: 126514

for Stuart Hastings. :-)

llvm-svn: 126469

llvm-svn: 126456

This is the error I got:

Debugger entered--Lisp error: (void-function split-string-and-unquote)
  (split-string-and-unquote command-line)
  (let* ((words ...) (program ...) (dir default-directory) (file-word ...) (file-subst ...) (args ...) (file ...) (filepart ...) (existing-buffer ...)) (pop-to$
  gud-common-init("/Volumes/data/lldb/svn/trunk/build/Debug/lldb" nil gud-lldb-marker-filter)
  lldb("/Volumes/data/lldb/svn/trunk/build/Debug/lldb")
  call-interactively(lldb)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

The gud-common-init elisp function references split-string-and-unquote function
which is not defined there.

llvm-svn: 126449

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

When making a DataExtractor from a Value that's got a ClangType, set the AddressByteSize from the AST Context.

llvm-svn: 126433

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

Previously we were using a set of preprocessor defines and returning an ArchSpec
without any OS/Vendor information.  This fixes an issue with plugin resolution
on Linux where a valid OS component is needed.

llvm-svn: 126404

The major issue this patch solves is that ArchSpec::SetTriple no longer depends
on the implementation of Host::GetArchitecture.  On linux, Host::GetArchitecture
calls ArchSpec::SetTriple, thus blowing the stack.

A second smaller point is that SetTriple now defaults to Host defined components
iff all OS, vendor and environment fields are not set.

llvm-svn: 126403

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

llvm-svn: 126271

llvm-svn: 126267