adding methods to C++ and objective C classes. In order to make methods, we
need the function prototype which means we need the arguments. Parsing these
could cause a circular reference that caused an  assertion.

Added a new typedef for the clang opaque types which are just void pointers:
lldb::clang_type_t. This appears in lldb-types.h.

This was fixed by enabling struct, union, class, and enum types to only get
a forward declaration when we make the clang opaque qual type for these
types. When they need to actually be resolved, lldb_private::Type will call
a new function in the SymbolFile protocol to resolve a clang type when it is
not fully defined (clang::TagDecl::getDefinition() returns NULL). This allows
us to be a lot more lazy when parsing clang types and keeps down the amount
of data that gets parsed into the ASTContext for each module. 

Getting the clang type from a "lldb_private::Type" object now takes a boolean
that indicates if a forward declaration is ok:

    clang_type_t lldb_private::Type::GetClangType (bool forward_decl_is_ok);
    
So function prototypes that define parameters that are "const T&" can now just
parse the forward declaration for type 'T' and we avoid circular references in
the type system.

llvm-svn: 115012

intrinsic being used.  Thanks to Chris Lattner for
pointing out the proper way to do it.

llvm-svn: 115006

 - the guard variable for the static result
   variable was being mistaken for the actual
   result value, causing IRForTarget to fail

 - LLVM builtins like memcpy were not being
   properly resolved; now they are resolved
   to the corresponding function in the target

llvm-svn: 114990

Replace the vestigial Value::GetOpaqueCLangQualType with the more correct Value::GetValueOpaqueClangQualType.

But mostly, move the ObjC Trampoline handling code from the MacOSX dyld plugin to the AppleObjCRuntime classes.

llvm-svn: 114935

can be allocated and manipulated.

llvm-svn: 114928

Added a virtual destructor to ClangUtilityFunction with a body to it cleans
itself up.

Moved our SharingPtr into the lldb_private namespace to keep it easy to make
an exports file that exports only what is needed ("lldb::*").

llvm-svn: 114771

interface in ClangASTContext. Also added two bool returning functions that
indicated if an opaque clang qual type is a CXX class type, and if it is an
ObjC class type.

Objective C classes now will get their methods added lazily as they are
encountered. The reason for this is currently, unlike C++, the 
DW_TAG_structure_type and owns the ivars, doesn't not also contain the
member functions. This means when we parse the objective C class interface
we either need to find all functions whose names start with "+[CLASS_NAME"
or "-[CLASS_NAME" and add them all to the class, or when we parse each objective
C function, we slowly add it to the class interface definition. Since objective
C's class doesn't change internal bits according to whether it has certain types
of member functions (like C++ does if it has virtual functions, or if it has
user ctors/dtors), I currently chose to lazily populate the class when each
functions is parsed. Another issue we run into with ObjC method declarations
is the "self" and "_cmd" implicit args are not marked as artificial in the
DWARF (DW_AT_artifical), so we currently have to look for the parameters by
name if we are trying to omit artificial function args if the language of the
compile unit is ObjC or ObjC++.

llvm-svn: 114722

 - Sema is now exported (and there was much rejoicing.)

 - Storage classes are now centrally defined.

Also fixed some bugs that the new LLVM picked up.

llvm-svn: 114622

llvm-svn: 114616

expression parser's behalf so that now we see the
full TranslationUnitDecl instead of just the
FunctionDecl.

llvm-svn: 114514

for C++ classes.  Replaced it with a less hacky approach:

 - If an expression is defined in the context of a
   method of class A, then that expression is wrapped as
   ___clang_class::___clang_expr(void*) { ... }
   instead of ___clang_expr(void*) { ... }.

 - ___clang_class is resolved as the type of the target
   of the "this" pointer in the method the expression
   is defined in.

 - When reporting the type of ___clang_class, a method
   with the signature ___clang_expr(void*) is added to
   that class, so that Clang doesn't complain about a
   method being defined without a corresponding
   declaration.

 - Whenever the expression gets called, "this" gets
   looked up, type-checked, and then passed in as the
   first argument.

This required the following changes:

 - The ABIs were changed to support passing of the "this"
   pointer as part of trivial calls.

 - ThreadPlanCallFunction and ClangFunction were changed
   to support passing of an optional "this" pointer.

 - ClangUserExpression was extended to perform the
   wrapping described above.

 - ClangASTSource was changed to revert the changes
   required by the hack.

 - ClangExpressionParser, IRForTarget, and
   ClangExpressionDeclMap were changed to handle
   different manglings of ___clang_expr flexibly.  This
   meant no longer searching for a function called
   ___clang_expr, but rather looking for a function whose
   name *contains* ___clang_expr.

 - ClangExpressionParser and ClangExpressionDeclMap now
   remember whether "this" is required, and know how to
   look it up as necessary.

A few inheritance bugs remain, and I'm trying to resolve
these.  But it is now possible to use "this" as well as
refer implicitly to member variables, when in the proper
context.

llvm-svn: 114384

to symbolicate things without the need for a valid process subclass.

llvm-svn: 113895

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

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

 - 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

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

llvm-svn: 113658

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

llvm-svn: 113437

with the Clang parser that prevents us from passing
Objective-C types to functions that expect C types.
This quick hack keeps us in business until that
interaction is fixed.

llvm-svn: 113429

certain functions from being resolved correctly.

Some functions (particularly varargs functions)
are BitCast before being called, and the problem
was that a CallInst where getCalledValue()
returned a BitCast ConstantExpr was not being
relocated at all.

This problem should now be resolved for the case
of BitCast.

llvm-svn: 113396

expressions correctly.  These produced a result
variable with an initializer but no store
instruction, and the store instruction was as
a result never rewritten to become a store to a
persistent variable.

Now if the result variable has an initializer
but is never used, we generate a (redundant)
store instruction for it, which is then later
rewritten into a (useful) store to the persistent
result variable.

llvm-svn: 113300

symbols with the same name and no debug information.
Also improved the way functions are called so we
don't automatically define them as variadic functions
in the IR.

llvm-svn: 113290

expressions.  If an expression dereferences an
invalid pointer, there will still be a crash -
just now the crash will be in the function
___clang_valid_pointer_check().

llvm-svn: 112785

expressions.  Values used by the expression are
checked by validation functions which cause the
program to crash if the values are unsafe.

Major changes:

- Added IRDynamicChecks.[ch], which contains the
  core code related to this feature

- Modified CommandObjectExpression to install the
  validator functions into the target process.

- Added an accessor to Process that gets/sets the
  helper functions

llvm-svn: 112690

persistent variables were staying around too long.
This caused the following problem:

- A persistent result variable is created for the
  result of an expression.  The pointer to the
  corresponding Decl is stored in the variable.

- The persistent variable is looked up during
  struct generation (correctly) using its Decl.

- Another expression defines a new result variable
  which happens to have a Decl in the same place
  as the original result variable.

- The persistent variable is looked up during
  struct generation using its Decl, but the old
  result variable appears first in the list and
  has the same Decl pointer.

The fix is to destroy parser-specific data when
it is no longer valid.

Also improved some logging as I diagnosed the
bug.

llvm-svn: 112540

storing pointers to objects inside a std::vector.
These objects can move around as the std::vector
changes, invalidating the pointers.

llvm-svn: 112527

debugger to insert self-contained functions for use by
expressions (mainly for error-checking).

In order to support detecting whether a crash occurred
in one of these helpers -- currently our preferred way
of reporting that an error-check failed -- added a bit
of support for getting the extent of a JITted function
in addition to just its base.

llvm-svn: 112324

The goal is to separate the parser's data from the data
belonging to the parser's clients.  This allows clients
to use the parser to obtain (for example) a JIT compiled
function or some DWARF code, and then discard the parser
state.

Previously, parser state was held in ClangExpression and
used liberally by ClangFunction, which inherited from
ClangExpression.  The main effects of this refactoring 
are:

- reducing ClangExpression to an abstract class that
  declares methods that any client must expose to the
  expression parser,

- moving the code specific to implementing the "expr"
  command from ClangExpression and
  CommandObjectExpression into ClangUserExpression,
  a new class,

- moving the common parser interaction code from
  ClangExpression into ClangExpressionParser, a new
  class, and

- making ClangFunction rely only on
  ClangExpressionParser and not depend on the
  internal implementation of ClangExpression.

Side effects include:

- the compiler interaction code has been factored
  out of ClangFunction and is now in an AST pass
  (ASTStructExtractor),

- the header file for ClangFunction is now fully
  documented,

- several bugs that only popped up when Clang was
  deallocated (which never happened, since the
  lifetime of the compiler was essentially infinite)
  are now fixed, and

- the developer-only "call" command has been
  disabled.

I have tested the expr command and the Objective-C
step-into code, which use ClangUserExpression and
ClangFunction, respectively, and verified that they
work.  Please let me know if you encounter bugs or
poor documentation.

llvm-svn: 112249

complex inlined examples.

StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
This is because inlined frames will have a PC value that is the same as the 
concrete frame that owns the inlined frame, yet the code locations for the
frame can be different. We also need to be able to get the real PC value for
a given frame so that variables evaluate correctly. To get the actual PC
value for a frame you can use:

    addr_t pc = frame->GetRegisterContext()->GetPC();

Some issues with the StackFrame stomping on its own symbol context were 
resolved which were causing the information to change for a frame when the
stack ID was calculated. Also the StackFrame will now correctly store the
symbol context resolve flags for any extra bits of information that were 
looked up (if you ask for a block only and you find one, you will alwasy have
the compile unit and function).

llvm-svn: 111964

which is now on by default. Frames are gotten from the unwinder as concrete
frames, then if inline frames are to be shown, extra information to track
and reconstruct these frames is cached with each Thread and exanded as needed.

I added an inline height as part of the lldb_private::StackID class, the class
that helps us uniquely identify stack frames. This allows for two frames to
shared the same call frame address, yet differ only in inline height.

Fixed setting breakpoint by address to not require addresses to resolve.

A quick example:

% cat main.cpp

% ./build/Debug/lldb test/stl/a.out 
Current executable set to 'test/stl/a.out' (x86_64).
(lldb) breakpoint set --address 0x0000000100000d31
Breakpoint created: 1: address = 0x0000000100000d31, locations = 1
(lldb) r
Launching 'a.out'  (x86_64)
(lldb) Process 38031 Stopped
* thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread
 277   	
 278   	      _CharT*
 279   	      _M_data() const
 280 ->	      { return  _M_dataplus._M_p; }
 281   	
 282   	      _CharT*
 283   	      _M_data(_CharT* __p)
(lldb) bt
thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
  frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280
  frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288
  frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606
  frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414
  frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14
  frame #5: pc = 0x0000000100000d08, where = a.out`start + 52

Each inline frame contains only the variables that they contain and each inlined
stack frame is treated as a single entity.

llvm-svn: 111877

ClangExpressionVariables for found external variables
as well as for struct members, replacing the Tuple
and StructMember data structures.

llvm-svn: 111859

to spawn a thread for each process that is being monitored. Previously
LLDB would spawn a single thread that would wait for any child process which
isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on
linux). The old single thread used to call wait4() with a pid of -1 which 
could cause it to reap child processes that it shouldn't have.

Re-wrote the way Function blocks are handles. Previously I attempted to keep
all blocks in a single memory allocation (in a std::vector). This made the
code somewhat efficient, but hard to work with. I got rid of the old BlockList
class, and went to a straight parent with children relationship. This new 
approach will allow for partial parsing of the blocks within a function.

llvm-svn: 111706

expression parser.  There shouldn't be four separate
classes encapsulating a variable.

ClangExpressionVariable is now meant to be the
container for all variable information.  It has
several optional components that hold data for
different subsystems.

ClangPersistentVariable has been removed; we now
use ClangExpressionVariable instead.

llvm-svn: 111600

in the IR transformation passes.

llvm-svn: 111388

llvm-svn: 111216

API fixes.

llvm-svn: 111202

cleaned up its API slightly.

llvm-svn: 111053

Also cleaned up its API a tiny bit (but not the
extensive amount that is actually needed.  That's
still coming.)

llvm-svn: 111049

more sane (i.e., removed dead arguments, made
sensible defaults, etc.)

llvm-svn: 110990

NameSearchContext.

llvm-svn: 110980