Use this to allow the lldb Driver to emit notifications for breakpoint modifications.
<rdar://problem/10619974>

llvm-svn: 150665

told to look in a namespace.

llvm-svn: 150590

New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association.
This provides SB classes for each of the main object types involved in providing formatter support:
 SBTypeCategory
 SBTypeFilter
 SBTypeFormat
 SBTypeSummary
 SBTypeSynthetic
plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions
For naming consistency, this patch also renames a lot of formatters-related classes.
Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side.
The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer.
An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes.
Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories.

llvm-svn: 150558

JIT when printing the values of registers (e.g.,
"expr $pc").  Now the expression parser can do this
in the IR interpreter without running code in the
inferior process.

llvm-svn: 150554

can be allocated in the process.

llvm-svn: 150523

Remove the functionality of using 'frame variable -w' to set a watchpoint now that 'watchpoint set variable/expression'
is working.  Also update the relevant test cases.

llvm-svn: 150514

llvm-svn: 150492

for assembly instructions to occasionally come
out empty.

llvm-svn: 150445

seems that sections in the memory module might be quite different from the
sections in the file module. Now we find all segments in the on disk file and
find that segment by name in the memory module and it is ok if any sections
from the file are missing in the memory image.

llvm-svn: 150443

Tracking modules down when you have a UUID and a path has been improved.

DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.

Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries. 

llvm-svn: 150426

anonymous types to each other unless they have
the same byte_size.

llvm-svn: 150422

"target modules lookup" also work with the
"--function" option, so you can search for
functions that aren't inlined.  This is the
same query that the expression parser makes, so
it's good for diagnosing situations where the
expression parser doesn't find a function you
think should be there.

llvm-svn: 150289

prettier.

llvm-svn: 150285

indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.

llvm-svn: 150279

detection of kernels into the object file and
adding a new category for raw binary images.
Fixed all clients who previously searched for
sections manually, making them use the object
file's facilities instead.

llvm-svn: 150272

llvm-svn: 150271

parser.  Specifically:

- ClangUserExpression now keeps weak pointers to the
  structures it needs and then locks them when needed.
  This ensures that they continue to be valid without
  leaking memory if the ClangUserExpression is long
  lived.

- ClangExpressionDeclMap, instead of keeping a pointer
  to an ExecutionContext, now contains an
  ExecutionContext.  This prevents bugs if the pointer
  or its contents somehow become stale.  It also no
  longer requires that ExecutionContexts be passed
  into any function except its initialization function,
  since it can count on the ExecutionContext still
  being around.

There's a lot of room for improvement (specifically,
ClangExpressionDeclMap should also use weak pointers
insetad of shared pointers) but this is an important
first step that codifies assumptions that already
existed in the code.

llvm-svn: 150217

by GetClangDeclContextContainingDIE, for better
debuggability.

llvm-svn: 150211

enable us to track the depth of parsing and what is being parsed. This
helps when trying to track down difficult type parsing issues and is only
enabled in non-production builds.

llvm-svn: 150203

Also fix a logic error for a missing return stmt. Oops.

llvm-svn: 150195

user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory. 

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many 
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the 
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for 
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.

llvm-svn: 150154

change (besides logging) is that now string
literals in the IR are ConstantDataArrays instead
of ConstantArrays.

llvm-svn: 150142

llvm-svn: 150134

llvm-svn: 150131

After discussions with Jim and Greg, modify the 'watchpoint set' command to become a mutiword command
with subcommand 'expression' and 'variable'.  The first subcommand is for supplying an expression to
be evaluated into an address to watch for, while the second is for watching a variable.

'watchpoint set expression' is a raw command, which means that you need to use the "--" option terminator
to end the '-w' or '-x' option processing and to start typing your expression.

Also update several test cases to comply and add a couple of test cases into TestCompletion.py,
in particular, test that 'watchpoint set ex' completes to 'watchpoint set expression ' and that
'watchpoint set var' completes to 'watchpoint set variable '.

llvm-svn: 150109

variables that are only available in symbols.

llvm-svn: 150103

parser now at least tries to generate IR for the
target.

llvm-svn: 150079

Also, provide and use accessors for the thread options on breakpoints so we
can control sending the appropriate events.

llvm-svn: 150057

information about the current frame rather than
the debug information about "this" and "self"
when determining the types of those pointers.
This allows expressions to work in frames that
don't have valid "this" and "self" pointers,
working around poor debug information.

llvm-svn: 150051

llvm-svn: 150039

llvm-svn: 150036

sufficiently general - it could only handle
literals and operations that didn't change the
data.  Now the constant evaluator passes APInt
values around, and can handle GetElementPtr
constants.

llvm-svn: 150034

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

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

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