expressions.  This involved three main changes:

 - In ClangUserExpression::ClangUserExpression(),
   we now insert the following lines into the
   expression:
     #define this ___clang_this
     #define self ___clang_self

 - In ClangExpressionDeclMap::GetDecls(), we
   special-case ___clang_(this|self) and instead
   look up "this" or "self"

 - In ClangASTSource, we introduce the capability
   to generate Decls with a different, overridden,
   name from the one that was requested, e.g.
   this for ___clang_this.

llvm-svn: 113866

llvm-svn: 113832

to any inferior process because the code was checking if no run args were
set and then adding and empty string. This was happening for environment
vars as well.

llvm-svn: 113831

to return the correct result.

Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct
result when there are no location lists.

Modified the "frame variable" command such that:
- if no arguments are given (dump all frame variables), then we only show
  variables that are currently in scope
- if some arguments are given, we show an error if the variable is out of 
  scope

llvm-svn: 113830

debug map showed that the location lists in the .o files needed some 
refactoring in order to work. The case that was failing was where a function
that was in the "__TEXT.__textcoal_nt" in the .o file, and in the 
"__TEXT.__text" section in the main executable. This made symbol lookup fail
due to the way we were finding a real address in the debug map which was
by finding the section that the function was in in the .o file and trying to
find this in the main executable. Now the section list supports finding a
linked address in a section or any child sections. After fixing this, we ran
into issue that were due to DWARF and how it represents locations lists. 
DWARF makes a list of address ranges and expressions that go along with those
address ranges. The location addresses are expressed in terms of a compile
unit address + offset. This works fine as long as nothing moves around. When
stuff moves around and offsets change between the remapped compile unit base
address and the new function address, then we can run into trouble. To deal
with this, we now store supply a location list slide amount to any location
list expressions that will allow us to make the location list addresses into
zero based offsets from the object that owns the location list (always a
function in our case). 

With these fixes we can now re-link random address ranges inside the debugger
for use with our DWARF + debug map, incremental linking, and more.

Another issue that arose when doing the DWARF in the .o files was that GCC
4.2 emits a ".debug_aranges" that only mentions functions that are externally
visible. This makes .debug_aranges useless to us and we now generate a real
address range lookup table in the DWARF parser at the same time as we index
the name tables (that are needed because .debug_pubnames is just as useless).
llvm-gcc doesn't generate a .debug_aranges section, though this could be 
fixed, we aren't going to rely upon it.

Renamed a bunch of "UINT_MAX" to "UINT32_MAX".

llvm-svn: 113829

was used to set the selected thread if none was selected.  Use a more robust
API to accomplish the task.

Also fixed an error found, while investigating, in CommandObjectThreadSelect::
Execute() where the return status was not properly set if successful.

As a result, both the stl step-in test cases with expectedFailure decorators now
passed.

llvm-svn: 113825

 - If you put a semicolon at the end of an expression,
   this no longer causes the expression parser to
   error out.  This was a two-part fix: first,
   ClangExpressionDeclMap::Materialize now handles
   an empty struct (such as when there is no return
   value); second, ASTResultSynthesizer walks backward
   from the end of the ASTs until it reaches something
   that's not a NullStmt.

 - ClangExpressionVariable now properly byte-swaps when
   printing itself.

 - ClangUtilityFunction now cleans up after itself when
   it's done compiling itself.

 - Utility functions can now use external functions just
   like user expressions.

 - If you end your expression with a statement that does
   not return a value, the expression now runs correctly
   anyway.

Also, added the beginnings of an Objective-C object
validator function, which is neither installed nor used
as yet.

llvm-svn: 113789

the binaries.

If the build* function is passed the compiler argument, for example, 'llvm-gcc',
it is passed as a make variable to the make command.  Otherwise, we check the
LLDB_CC environment variable; if it is defined, it is passed as a make variable
to the make command.

If neither the compiler keyword argument nor the LLDB_CC environment variable is
specified, no CC make variable is passed to the make command.  The Makefile gets
to define the default CC being used.

--------------------------------------------------------------------------------
Example usage follows:

o Via the keyword argument:

class ArrayTypesTestCase(TestBase):

    mydir = "array_types"

    @unittest2.skipUnless(sys.platform.startswith("darwin"), "requires Darwin")
    def test_with_dsym_and_run_command(self):
        """Test 'frame variable var_name' on some variables with array types."""
        self.buildDsym(compiler='llvm-gcc')
        self.array_types()
...

o Via LLDB_CC environment variable:

$ LLDB_CC=llvm-gcc ./dotest.py -v -t array_types
----------------------------------------------------------------------
Collected 4 tests

test_with_dsym_and_python_api (TestArrayTypes.ArrayTypesTestCase)
Use Python APIs to inspect variables with array types. ... 
os command: [['/bin/sh', '-c', 'make clean; make MAKE_DSYM=YES CC=llvm-gcc']]
output: rm -rf "a.out" "a.out.dSYM"  main.o main.d
llvm-gcc -arch x86_64 -gdwarf-2 -O0 -arch x86_64 -gdwarf-2 -O0  -c -o main.o main.c
llvm-gcc -arch x86_64 -gdwarf-2 -O0  main.o -o "a.out"
/usr/bin/dsymutil  -o "a.out.dSYM" "a.out"

...

llvm-svn: 113781

llvm-svn: 113756

llvm-svn: 113755

llvm-svn: 113753

llvm-svn: 113751

llvm-svn: 113750

llvm-svn: 113748

llvm-svn: 113738

map on macosx.

llvm-svn: 113737

frame variables.

llvm-svn: 113736

point to.

llvm-svn: 113735

llvm-svn: 113734

no elements so that they at least have 1 element. 

Added the ability to show the declaration location of variables to the 
"frame variables" with the "--show-declaration" option ("-c" for short).

Changed the "frame variables" command over to use the value object code
so that we use the same code path as the public API does when accessing and
displaying variable values.

llvm-svn: 113733

llvm-svn: 113732

static class array. It turns out that gcc 4.2 will emit DWARF that correctly
describes the PointType, but it will incorrectly emit debug info for the
"g_points" array where the following things are wrong:
 - the DW_TAG_array_type won't have a subrange info
 - the DW_TAG_variable for "g_points" won't have a valid byte size, so even
   though we know the size of PointType, we can't infer the actual size
   of the array by dividing the size of the variable by the number of
   elements.

We want to make sure clang and llvm-gcc handle this correctly.

llvm-svn: 113730

union, or class that contained an enumeration type. When I was creating
the clang enumeration decl, I wasn't calling "EnumDecl::setIntegerType (QualType)" 
which means that if the enum decl was ever asked to figure out it's bit width
(getTypeInfo()) it would crash. We didn't run into this with enum types that 
weren't inside classes because the DWARF already told us how big the type was
and when we printed an enum we would never need to calculate the size, we
would use the pre-cached byte size we got from the DWARF. When the enum was 
in a struct/union/class and we tried to layout the struct, the layout code
would attempt to get the type info and segfault.

llvm-svn: 113729

Fixed an issue where LLDB would fail to set a breakpoint by
file and line if the DWARF line table has multiple file entries
in the support files for a source file.

llvm-svn: 113721

we cached remapping information using the old nlist index to the
new symbol index, yet we tried to lookup the symbol stubs that
were for symbols that had been remapped by ID instead of using
the new symbol index. This is now fixed and the mach-o symbol tables
are fixed.

Use the delta between two vector entries to determine the stride
in case any padding is inserted by compilers for bsearch calls
on symbol tables when finding symbols by their original ID.

llvm-svn: 113719

llvm-svn: 113715

missing arguments for some of the command options.

llvm-svn: 113714

it with llvm::sys::Program::FindProgramByName.

llvm-svn: 113709

They will now be represented as:
eSymbolTypeFunction: eSymbolTypeCode with IsDebug() == true
  eSymbolTypeGlobal: eSymbolTypeData with IsDebug() == true and IsExternal() == true
  eSymbolTypeStatic: eSymbolTypeData with IsDebug() == true and IsExternal() == false

This simplifies the logic when dealing with symbols and allows for symbols
to be coalesced into a single symbol most of the time.

Enabled the minimal symbol table for mach-o again after working out all the
kinks. We now get nice concise symbol tables and debugging with DWARF in the
.o files with a debug map in the binary works well again. There were issues
where the SymbolFileDWARFDebugMap symbol file parser was using symbol IDs and
symbol indexes interchangeably. Now that all those issues are resolved 
debugging is working nicely.

llvm-svn: 113678

llvm-svn: 113674

llvm-svn: 113673

to specify a one-liner (either scripting or lldb command) inline.

Refactored CommandObjectBreakpointCommandAdd::Execute() a little bit and added
some comments.

Sn now, we use:

breakpoint command add -p 1 -o "conditional_break.stop_if_called_from_a()"

to specify a Python one-liner as the callback for breakpoint #1.

llvm-svn: 113672

llvm-svn: 113669

llvm-svn: 113661

SBValue to access it.  For now this is just the result of ObjC NSPrintForDebugger,
but could be extended.  Also store the results of the ObjC Object Printer in a
Stream, not a ConstString.

llvm-svn: 113660

Mainly ExecuteFunction should save & restore the currently selected Thread & Frame.

llvm-svn: 113658

When the debugger updates its symbol context, if no thread or frame are selected select the first thread's 0th frame.

llvm-svn: 113657

llvm-svn: 113655

Make sure the address passed into SymbolContext::DumpStopContext() is valid before trying to calculate any offsets.

llvm-svn: 113645

There was a check to make sure that the frame had a valid function before the expression parser would allow decl lookups which was not needed. After removing this you can evaluate expressions correctly when stopped in a frame that only has a symbol or has no symbol context at all.

llvm-svn: 113611