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

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