into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:

virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);

virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);

There is now a new class specifically designed to hold register values: 
        lldb_private::RegisterValue
        
The new register context calls that subclasses must implement are:

virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0;

virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0;

The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the 
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..). 

All RegiterContext and other sources have been switched over to using the new
regiter value class.

llvm-svn: 131096

they are treated as pointers of type (void*).  This
allows reading of environ, for instance.

llvm-svn: 131063

variables be evaluated statically.

Also fixed a bug that caused the results of
statically-evaluated expressions to be materialized
improperly.

This bug also removes some duplicate code.

llvm-svn: 131042

llvm-svn: 130701

pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will
stay around as long as that shared pointer stays around.

llvm-svn: 130035

Add support for "dynamic values" for C++ classes.  This currently only works for "frame var" and for the
expressions that are simple enough to get passed to the "frame var" underpinnings.  The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.

The behavior of "frame var" is controlled in two ways.  You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.

There's also a general setting:

target.prefer-dynamic-value (boolean) = 'true'

which is consulted if you call "frame var" without supplying a value for the -d option.

llvm-svn: 129623

tables.

llvm-svn: 129500

    
This patch fixes all of the warnings due to unordered initialization lists.

Patch by Marco Minutoli.

llvm-svn: 129290

respectively.

llvm-svn: 128720

Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves.  That means all the ValueObject evaluate me type functions that used to require a Frame object now do not.  I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated.

llvm-svn: 128593

an architecture into ArchSpec:

uint32_t
ArchSpec::GetMinimumOpcodeByteSize() const;

uint32_t
ArchSpec::GetMaximumOpcodeByteSize() const;

Added an AddressClass to the Instruction class in Disassembler.h.
This allows decoded instructions to know know if they are code,
code with alternate ISA (thumb), or even data which can be mixed
into code. The instruction does have an address, but it is a good
idea to cache this value so we don't have to look it up more than 
once.

Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't
getting set.

Changed:

	bool
	SymbolContextList::AppendIfUnique (const SymbolContext& sc);

To:
	bool
	SymbolContextList::AppendIfUnique (const SymbolContext& sc, 
									   bool merge_symbol_into_function);

This function was typically being used when looking up functions
and symbols. Now if you lookup a function, then find the symbol,
they can be merged into the same symbol context and not cause
multiple symbol contexts to appear in a symbol context list that
describes the same function.

Fixed the SymbolContext not equal operator which was causing mixed
mode disassembly to not work ("disassembler --mixed --name main").

Modified the disassembler classes to know about the fact we know,
for a given architecture, what the min and max opcode byte sizes
are. The InstructionList class was modified to return the max
opcode byte size for all of the instructions in its list.
These two fixes means when disassemble a list of instructions and dump 
them and show the opcode bytes, we can format the output more 
intelligently when showing opcode bytes. This affects any architectures
that have varying opcode byte sizes (x86_64 and i386). Knowing the max
opcode byte size also helps us to be able to disassemble N instructions
without having to re-read data if we didn't read enough bytes.

Added the ability to set the architecture for the disassemble command.
This means you can easily cross disassemble data for any supported 
architecture. I also added the ability to specify "thumb" as an 
architecture so that we can force disassembly into thumb mode when
needed. In GDB this was done using a hack of specifying an odd
address when disassembling. I don't want to repeat this hack in LLDB,
so the auto detection between ARM and thumb is failing, just specify
thumb when disassembling:

(lldb) disassemble --arch thumb --name main

You can also have data in say an x86_64 file executable and disassemble
data as any other supported architecture:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
(lldb) run
(lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes
0x100001080:  0xb580 push   {r7, lr}
0x100001082:  0xaf00 add    r7, sp, #0

Fixed Target::ReadMemory(...) to be able to deal with Address argument object
that isn't section offset. When an address object was supplied that was
out on the heap or stack, target read memory would fail. Disassembly uses
Target::ReadMemory(...), and the example above where we disassembler thumb
opcodes in an x86 binary was failing do to this bug.

llvm-svn: 128347

plugin by name on the command line for when there is more than one disassembler
plugin.

Taught the Opcode class to dump itself so that "disassembler -b" will dump
the bytes correctly for each opcode type. Modified all places that were passing
the opcode bytes buffer in so that the bytes could be displayed to just pass
in a bool that indicates if we should dump the opcode bytes since the opcode
now lives inside llvm_private::Instruction.

llvm-svn: 128290

public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.

llvm-svn: 128239

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

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

llvm-svn: 127825

llvm-svn: 127634

or 'self' variable was not properly read if the compiler
optimized it into a register.

llvm-svn: 126973

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

Fixed a hang in the expression parser's result synthesizer that occurs when the function generated for the expression is completely empty except for a NULL_STMT.  This happens sometimes when the parser returns errors.

llvm-svn: 126251

    clang_type_t
    GetClangFullType(); // Get a completely defined clang type

    clang_type_t
    GetClangLayoutType(); // Get a clang type that can be used for type layout
    
    clang_type_t
    GetClangForwardType(); // A type that can be completed if needed, but is more efficient.
    

llvm-svn: 125691

now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
  selection.

llvm-svn: 125602

- Objective-C constant strings were being
  NULL-terminated erroneously.

- Empty Objective-C constant strings were not
  being generated correctly.

Also added the template for a test of these
fixes.

llvm-svn: 125314

llvm-svn: 124928

diagnostics of Clang AST classes for the purpose of
debugging the types LLDB produces for DWARF objects.

The ASTDumper is currently only used in log output
if you enable verbose mode in the expression log:

log enable -v lldb expr

Its output then appears in the log for external
variables used by the expr command.

llvm-svn: 124703

llvm-svn: 124643

lldb_private::Function objects. Previously the SymbolFileSymtab subclass
would return lldb_private::Symbol objects when it was asked to find functions.

The Module::FindFunctions (...) now take a boolean "bool include_symbols" so
that the module can track down functions and symbols, yet functions are found
by the SymbolFile plug-ins (through the SymbolVendor class), and symbols are
gotten through the ObjectFile plug-ins.

Fixed and issue where the DWARF parser might run into incomplete class member
function defintions which would make clang mad when we tried to make certain
member functions with invalid number of parameters (such as an operator=
operator that had no parameters). Now we just avoid and don't complete these
incomplete functions.

llvm-svn: 124359

the "virtual" flag when importing a C++ function
declaration.  Made changes to LLDB to support other
changes in Clang.

llvm-svn: 124355

user doesn't have to enable logging to see where
something went wrong.

llvm-svn: 124342

llvm-svn: 124250

it to interpret a "this" variable that was merely
a pointer -- that is, not a class pointer -- as
meaning that the current context was inside a C++
method.  This bug would prevent expressions from
evaluating correctly in regular C code if there
was a pointer variable named "this" in scope.

llvm-svn: 124117

llvm-svn: 124051

llvm-svn: 124014

Added a safeguard to ensure that the user does not create variables that override persistent result variables.

llvm-svn: 124001

llvm-svn: 123855

500 ms.

Make MachThreadList more threadsafe.

Added code to make sure the thread register state was properly flushed for x86_64.

Fixed an missing return code for the current thread in the new thread suffix code.

Improved debugserver logging.

llvm-svn: 123815

support for minimal type import functionality.

llvm-svn: 123787

llvm-svn: 123784

I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.

llvm-svn: 123762

Apple's Objective-C 2.0 runtime.  They are enabled
if the Objective-C runtime has the proper version.

llvm-svn: 123694