Refine the 'watchpoint set' command to now require either the '-v' option (for watching of a variable) or
the '-e' option (for watching of an address) to be present.

Update some existing test cases with the required option and add some more test cases.

Since the '-v' option takes <variable-name> and the '-e' option takes <expr> as the command arg,
the existing infrastructure for generating the option usage can produce confusing help message,
like:

  watchpoint set -e [-w <watch-type>] [-x <byte-size>] <variable-name | expr>
  watchpoint set -v [-w <watch-type>] [-x <byte-size>] <variable-name | expr>

The solution adopted is to provide an extra member field to the struct CommandArgumentData called
(uint32_t)arg_opt_set_association, whose purpose is to link this particular argument data with some
option set(s).  Also modify the signature of CommandObject::GetFormattedCommandArguments() to:

  GetFormattedCommandArguments (Stream &str, uint32_t opt_set_mask = LLDB_OPT_SET_ALL)

it now takes an additional opt_set_mask which can be used to generate a filtered formatted command
args for help message.

Options::GenerateOptionUsage() impl is modified to call the GetFormattedCommandArguments() appropriately.
So that the help message now looks like:

  watchpoint set -e [-w <watch-type>] [-x <byte-size>] <expr>
  watchpoint set -v [-w <watch-type>] [-x <byte-size>] <variable-name>

rdar://problem/10703256

llvm-svn: 150032

quite as busy.

llvm-svn: 150005

for types that can be uniqued to the given type.
This is especially helpful when types are missing
file and line information.

llvm-svn: 150004

Add help string for 'frame variable' to link to 'watchpoint set' which allows for using an expression to specify the address to watch for.

rdar://problem/10703290

llvm-svn: 149917

code.  Removing these.

llvm-svn: 149903

llvm-svn: 149900

llvm-svn: 149899

llvm-svn: 149893

Plus mark the virtual inheritance test cases as expected failures.

llvm-svn: 149891

working, but not functions). I need to check on a few things to make sure 
I am registering everything correctly in the right order and in the right
contexts.

llvm-svn: 149858

interface (.i) files for each class.

Changed the FindFunction class from:

uint32_t
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

uint32_t
SBModule::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

To:

lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.

Exposed properties for lldb.SBSymbolContextList in python:

lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list

This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:

sc_list = lldb.target.FindFunctions("erase")

for function in sc_list.functions:
    print function
for symbol in sc_list.symbols:
    print symbol

Exposed properties for the lldb.SBSymbolContext objects in python:

lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol


Exposed properties for the lldb.SBBlock objects in python:

lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok

SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.

SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:

lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
                       bool arguments,
                       bool locals,
                       bool statics,
                       lldb::DynamicValueType use_dynamic);

lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
                       bool arguments,
                       bool locals,
                       bool statics);

When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.

When a SBTarget is used, global an static variables can be viewed without a
running process.

llvm-svn: 149853

for types and comparing decl context matches.

llvm-svn: 149812

in the DWARF plug-in.

llvm-svn: 149811

Fixed "target modules list" (aliased to "image list") to output more information
by default. Modified the "target modules list" to have a few new options:

"--header" or "-h" => show the image header address
"--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library)

Removed the "--symfile-basename" or "-S" option, and repurposed it to 
"--symfile-unique" "-S" which will show the symbol file if it differs from
the executable file.

ObjectFile's can now be loaded from memory for cases where we don't have the
files cached locally in an SDK or net mounted root. ObjectFileMachO can now
read mach files from memory.

Moved the section data reading code into the ObjectFile so that the object
file can get the section data from Process memory if the file is only in
memory.

lldb_private::Module can now load its object file in a target with a rigid 
slide (very common operation for most dynamic linkers) by using:

bool 
Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed)

lldb::SBModule() now has a new constructor in the public interface:

SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr);

This will find an appropriate ObjectFile plug-in to load an image from memory
where the object file header is at "header_addr".

llvm-svn: 149804

LLVM/Clang.  This brings in several fixes, including:

- Improvements in the Just-In-Time compiler's
  allocation of memory: the JIT now allocates
  memory in chunks of sections, improving its
  ability to generate relocations.  I have
  revamped the RecordingMemoryManager to reflect
  these changes, as well as to get the memory
  allocation and data copying out fo the
  ClangExpressionParser code.  Jim Grosbach wrote
  the updates to the JIT on the LLVM side.

- A new ExternalASTSource interface to allow LLDB to
  report accurate structure layout information to
  Clang.  Previously we could only report the sizes
  of fields, not their offsets.  This meant that if
  data structures included field alignment
  directives, we could not communicate the necessary
  alignment to Clang and accesses to the data would
  fail.  Now we can (and I have update the relevant
  test case).  Thanks to Doug Gregor for implementing
  the Clang side of this fix.

- The way Objective-C interfaces are completed by
  Clang has been made consistent with RecordDecls;
  with help from Doug Gregor and Greg Clayton I have
  ensured that this still works.

- I have eliminated all local LLVM and Clang patches,
  committing the ones that are still relevant to LLVM
  and Clang as needed.

I have tested the changes extensively locally, but
please let me know if they cause any trouble for you.

llvm-svn: 149775

Changed the lldb.SBModule.section[<str>] property to return a single section.

Added a lldb.SBSection.addr property which returns an lldb.SBAddress object.

llvm-svn: 149755

instead of the __repr__. __repr__ is a function that should return an
expression that can be used to recreate an python object and we were using
it to just return a human readable string.

Fixed a crasher when using the new implementation of SBValue::Cast(SBType).

Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general
improvements to the API.

Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't
correctly handle not having a target.

llvm-svn: 149743

llvm-svn: 149741

llvm-svn: 149710

llvm-svn: 149707

Fixing issues where synthetic children providers for STL containers std::list and std::map where not doing their job properly

llvm-svn: 149700

lldb.SBValueList now exposes the len() method and also allows item access:

lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range
lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches)
lldb.SBValueList[<re>]  - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches

lldb.SBFrame now exposes:

lldb.SBFrame.variables => SBValueList of all variables that are in scope
lldb.SBFrame.vars => see lldb.SBFrame.variables
lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame
lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame
lldb.SBFrame.args => see lldb.SBFrame.arguments
lldb.SBFrame.statics => SBValueList of all static variables
lldb.SBFrame.registers => SBValueList of all registers for the current frame
lldb.SBFrame.regs => see lldb.SBFrame.registers

Combine any of the above properties with the new lldb.SBValueList functionality
and now you can do:

y = lldb.frame.vars['rect.origin.y']

or

vars = lldb.frame.vars
for i in range len(vars):
  print vars[i]

Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path
for any variable or child within the variable. This makes it easier to get a
value from the current frame like "rect.origin.y". The resulting value is also
not a constant result as expressions will return, but a live value that will
continue to track the current value for the variable expression path.

lldb.SBValue now exposes:

lldb.SBValue.unsigned => unsigned integer for the value
lldb.SBValue.signed => a signed integer for the value

llvm-svn: 149684

llvm-svn: 149673

lldb.SBModule.section and lldb.SBModule.sections property access.

llvm-svn: 149665

Adding support for an "equivalents map". This can be useful when compilers emit multiple, different names for the same actual type. In such scenarios, one of the type names can actually be found during a type lookup, while the others are just aliases. This can cause issues when trying to work with these aliased names and being unable to resolve them to an actual type (e.g. getting an SBType for the aliased name).
Currently, no code is using this feature, since we can hopefully rely on the new template support in SBType to get the same stuff done, but the support is there just in case it turns out to be useful for some future need.

llvm-svn: 149661

uint32_t
SBType::GetNumberOfTemplateArguments ();

lldb::SBType
SBType::GetTemplateArgumentType (uint32_t idx);

lldb::TemplateArgumentKind
SBType::GetTemplateArgumentKind (uint32_t idx);

Some lldb::TemplateArgumentKind values don't have a corresponding SBType
that will be returned from SBType::GetTemplateArgumentType(). This will
help our data formatters do their job by being able to find out the
type of template params and do smart things with those.

llvm-svn: 149658

llvm-svn: 149656

When used in conjunction with --inline-children, this option will cause the names of the values to be omitted from the output. This can be beneficial in cases such as vFloat, where it will compact the representation from
([0]=1,[1]=2,[2]=3,[3]=4) to (1, 2, 3, 4).
Added a test case to check that the new option works correctly.
Also took some time to revisit SummaryFormat and related classes and tweak them for added readability and maintainability.
Finally, added a new class name to which the std::string summary should be applied.

llvm-svn: 149644

bool
lldb_private::StateIsStoppedState (StateType state, bool must_exist)

instead.

llvm-svn: 149637

should use Target::ReadMemory() call to read from the file section offset address.
Also remove the @expectedFailure decorator..

'target variable' command fails if the target program has been run
rdar://problem/9763907

llvm-svn: 149629

This affected bash users.

llvm-svn: 149623

otherwise we will have a launched process stopped at the entry point and
it will get reparented when debugserver goes away and we won't be able to
kill the process later.

llvm-svn: 149622

llvm-svn: 149609

ensure that changes to the typemaps are properly detected and cause SWIG to rebuild LLDBWrapPython.cpp

llvm-svn: 149606

a type when we have a forward declaration. We always have found a 
type by basename, but now we also compare the decl context of the 
die we are trying to complete with the matches we find from the accelerator
tables to ensure we get the right one.

llvm-svn: 149593

negative hex values. Also added a very rudimentary version of the == and !=
operators to the lldb.value helper class.

llvm-svn: 149564

llvm-svn: 149529

llvm-svn: 149523

llvm-svn: 149519

You can now access a frame in a thread using:

lldb.SBThread.frame[int] -> lldb.SBFrame object for a frame in a thread

Where "int" is an integer index. You can also access a list object with all of
the frames using:

lldb.SBThread.frames => list() of lldb.SBFrame objects

All SB objects that give out SBAddress objects have properties named "addr"

lldb.SBInstructionList now has the following convenience accessors for len() and
instruction access using an index:

insts = lldb.frame.function.instructions
for idx in range(len(insts)):
    print insts[idx]
    
Instruction lists can also lookup an isntruction using a lldb.SBAddress as the key:

pc_inst = lldb.frame.function.instructions[lldb.frame.addr]

lldb.SBProcess now exposes:

lldb.SBProcess.is_alive => BOOL Check if a process is exists and is alive
lldb.SBProcess.is_running => BOOL check if a process is running (or stepping):
lldb.SBProcess.is_running => BOOL check if a process is currently stopped or crashed:
lldb.SBProcess.thread[int] => lldb.SBThreads for a given "int" zero based index
lldb.SBProcess.threads => list() containing all lldb.SBThread objects in a process

SBInstruction now exposes:
lldb.SBInstruction.mnemonic => python string for instruction mnemonic
lldb.SBInstruction.operands => python string for instruction operands
lldb.SBInstruction.command => python string for instruction comment

SBModule now exposes:

lldb.SBModule.uuid => uuid.UUID(), an UUID object from the "uuid" python module
lldb.SBModule.symbol[int] => lldb.Symbol, lookup symbol by zero based index
lldb.SBModule.symbol[str] => list() of lldb.Symbol objects that match "str"
lldb.SBModule.symbol[re] => list() of lldb.Symbol objecxts that match the regex
lldb.SBModule.symbols => list() of all symbols in a module

  
SBAddress objects can now access the current load address with the "lldb.SBAddress.load_addr"
property. The current "lldb.target" will be used to try and resolve the load address.

Load addresses can also be set using this accessor:

addr = lldb.SBAddress()
addd.load_addr = 0x123023

Then you can check the section and offset to see if the address got resolved.

SBTarget now exposes:

lldb.SBTarget.module[int] => lldb.SBModule from zero based module index
lldb.SBTarget.module[str] => lldb.SBModule by basename or fullpath or uuid string
lldb.SBTarget.module[uuid.UUID()] => lldb.SBModule whose UUID matches
lldb.SBTarget.module[re] => list() of lldb.SBModule objects that match the regex
lldb.SBTarget.modules => list() of all lldb.SBModule objects in the target

SBSymbol now exposes:

lldb.SBSymbol.name => python string for demangled symbol name
lldb.SBSymbol.mangled => python string for mangled symbol name or None if there is none
lldb.SBSymbol.type => lldb.eSymbolType enum value
lldb.SBSymbol.addr => SBAddress object that represents the start address for this symbol (if there is one)
lldb.SBSymbol.end_addr => SBAddress for the end address of the symbol  (if there is one)
lldb.SBSymbol.prologue_size => pythin int containing The size of the prologue in bytes
lldb.SBSymbol.instructions => SBInstructionList containing all instructions for this symbol

SBFunction now also has these new properties in addition to what is already has:
lldb.SBFunction.addr => SBAddress object that represents the start address for this function
lldb.SBFunction.end_addr => SBAddress for the end address of the function
lldb.SBFunction.instructions => SBInstructionList containing all instructions for this function

SBFrame now exposes the SBAddress for the frame:
lldb.SBFrame.addr => SBAddress which is the section offset address for the current frame PC

These are all in addition to what was already added. Documentation and website
updates coming soon.

llvm-svn: 149489