This should fix the build breakage caused by the api change in 178663.

llvm-svn: 178700

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191

went wrong and we tried to get layout information
that wasn't there.

<rdar://problem/13490170>

llvm-svn: 177880

Clang requires them to have complete types, but
we were previously only completing them if they
were of tag or Objective-C object types.

I have implemented a method on the ASTImporter
whose job is to complete a type.  It handles not
only the cases mentioned above, but also array
and atomic types.

<rdar://problem/13446777>

llvm-svn: 177672

when clang asked for them by name.

llvm-svn: 177085

Match the new declaration of clang::ASTContext::getFunctionType introduced in clang r176726. Fix the build of lldb

llvm-svn: 176790

counters for a variety of metrics associated
with expression parsing.  This should give some
idea of how much work the expression parser is
doing on Clang's behalf, and help with hopefully
reducing that load over time.

<rdar://problem/13210748> Audit type search/import for expressions

llvm-svn: 176714

  - made sure we tell Clang not to try to
    complete the type since it can't be
    completed from its origin any more; and

  - fixed a silly bug where we tried to
    forget about the original decl's origins
    rather than the deported decl's origin.

These produced some crashes in ptr_refs,
especially under libgmalloc.

<rdar://problem/13256150>

llvm-svn: 176233

changing the ClangASTSource to return a bool instead
of returning a list of results.  Our testsuite mostly
works with this change, but some minor issues may
remain both on LLDB's side and on Clang's side.

llvm-svn: 174949

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

llvm-svn: 173463

The results from Clang name lookups changed to
be ArrayRefs, so I had to change the way we
check for the presence of a result and the way
we iterate across results.

llvm-svn: 170927

for reporting class types from Objective-C runtime
class symbols.  Instead, LLDB now queries the 
Objective-C runtime for class types.

We have also added a (minimal) Objective-C runtime
type vendor for Objective-C runtime version 1, to 
prevent regressions when calling class methods in
the V1 runtime.

Other components of this fix include:

- We search the Objective-C runtime in a few more
  places.

- We enable enumeration of all members of
  Objective-C classes, which Clang does in certain
  circumstances.

- SBTarget::FindFirstType and SBTarget::FindTypes
  now query the Objective-C runtime as needed.

- I fixed several test cases.

<rdar://problem/12885034>

llvm-svn: 170601

- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945

a type, and we find it in the origin for that
type, don't look anywhere else; just report it.

<rdar://problem/12675970>

llvm-svn: 168766

This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
 - the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
 - if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine

llvm-svn: 167569

the runtime if we have complete debug information
for a class.

Also made the Objective-C language runtime return
NULL when asked for the complete debug information
(i.e., information from DWARF, not information from
the runtime) if that information isn't present.  It
used to return a non-authoritative version, which
made it hard for clients to determine whether
complete debug information was available.

<rdar://problem/12608895>

llvm-svn: 167299

top-of-tree.  Removed all local patches and llvm.zip.

The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur.  Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.

llvm-svn: 164563

not correctly store the contents of Objective-C
classes.  This was due to a combination of
factors:

  1) Types were only being completed if we were
     looking inside them for specific ivars
     (using FindExternalVisibleDeclsByName). 
     We now look the complete type up at every
     FindExternalLexicalDecls.

  2) Even if the types were completed properly,
     ValueObjectConstResult overrode the type
     of every ValueObject using the complete type
     for its class from the debug information.
     Superclasses of complete classes are not
     guaranteed to be complete.  Although "frame
     variable" uses the debug information,
     the expression parser does now piece together
     complete types at every level (as described
     in Bullet 1), so I provided a way for the
     expression parser to prevent overriding.

  3) Type sizes were being miscomputed by
     ClangASTContext.  It ignored the ISA pointer
     and only counted fields.  We now correctly
     count the ISA in the size of an object.

<rdar://problem/12315386>

llvm-svn: 164333

information from the Objective-C runtime.

This patch takes the old AppleObjCSymbolVendor and
replaces it with an AppleObjCTypeVendor, which is
much more lightweight.  Specifically, the SymbolVendor
needs to pretend that there is a backing symbol file
for the Types it vends, whereas a TypeVendor only
vends bare ClangASTTypes.  These ClangASTTypes only
need to exist in an ASTContext.

The ClangASTSource now falls back to the runtime's
TypeVendor (if one exists) if the debug information
doesn't find a complete type for a particular
Objective-C interface.  The runtime's TypeVendor
maintains an ASTContext full of types it knows about,
and re-uses the ISA-based type query information used
by the ValueObjects.

Currently, the runtime's TypeVendor doesn't provide
useful answers because we haven't yet implemented a
way to iterate across all ISAs contained in the target
process's runtime.  That's the next step.

llvm-svn: 163651

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860

setting breakpoints.  That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load notification, and start removing modules from
the list.  This change adds a GetMutex accessor to the ModuleList class, and
uses it whenever we are accessing the target's ModuleList (as returned by GetImages().)

<rdar://problem/11552372>

llvm-svn: 157668

into FindExternalVisibleDeclsByName.

llvm-svn: 155561

potential crash if the underlying type couldn't
be completed.

llvm-svn: 154234

In a prior commit, I changed the parameters around on a ModuleList::FindTypes where the old parameters that existing clients were using would have been compatible, so I renamed ModuleList::FindTypes to ModuleList::FindTypes2. Then I made fixes and verified I updated and fixed all client code, but I forgot to rename the function back to ModuleList::FindTypes(). I am doing that now and also cleaning up the C++ dynamic type code a bit.

llvm-svn: 154182

correctly if the setter/getter were not present
in the debug information.  The fixes are as follows:

- We not only look for the method by its full name,
  but also look for automatically-generated methods
  when searching for a selector in an Objective-C
  interface.  This is necessary to find accessors.

- Extract the getter and setter name from the
  DW_TAG_APPLE_Property declaration in the DWARF
  if they are present; generate them if not.

llvm-svn: 154067

Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482

use QualType contents unchecked.

llvm-svn: 153201

expression parser code.

llvm-svn: 153128

Now when LLDB reports a variable, it has a
complete type.  Similarly, when it reports
members of a struct, it completes their types.
Also, when it creates the result variable for
an expression, it ensures that variable's type
is complete.

This ensures compliance with Clang's
expectations, preventing potential crashes.

llvm-svn: 152771

AST importer because we're seeing occasional
crashes.

llvm-svn: 151541

Objective-C classes.  This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).

This involved the following main changes:

- The ObjCLanguageRuntime now knows how to hunt
  for the authoritative version of an Objective-C
  type.  It looks for the symbol indicating a
  definition, and then gets the type from the
  module containing that symbol.

- ValueObjects now report their type with a
  potential override, and the override is set if
  the type of the ValueObject is an Objective-C
  class or pointer type that is defined somewhere
  other than the original reported type.  This
  means that "frame variable" will always use the
  complete type if one is available.

- The ClangASTSource now looks for the complete
  type when looking for ivars.  This means that
  "expr" will always use the complete type if one
  is available.

- I added a testcase that verifies that both
  "frame variable" and "expr" work.

llvm-svn: 151214

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

code.  Removing these.

llvm-svn: 149903

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

due to RTTI worries since llvm and clang don't use RTTI, but I was able to 
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared 
pointer from just a pointer, which is also easily solved using the 
std::tr1::enable_shared_from_this class. 

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).

llvm-svn: 149207

for each ObjCInterfaceDecl was imposing performance
penalties for Objective-C apps.  Instead, we now use
the normal function query mechanisms, which use the
relevant accelerator tables.

This fix also includes some modifications to the
SymbolFile which allow us to find Objective-C methods
and report their Clang Decls correctly.

llvm-svn: 148457

more information.

llvm-svn: 148144

"id" from being found by the parser as an
externally-defined type.  Before, "id" would
sometimes make it through if it was defined in
a namespace, but this sometimes caused
confusion, for example when it conflicted with
std::locale::id.

llvm-svn: 146891

the expression parser to locate instances where
dyn_cast<>() and isa<>() are used on types, and
replace them with getAs<>() as appropriate.

The difference is that dyn_cast<>() and isa<>()
are essentially LLVM/Clang's equivalent of RTTI
-- that is, they try to downcast the object and
return NULL if they cannot -- but getAs<>() can
traverse typedefs to perform a semantic cast.

llvm-svn: 146537

in the context in which it was originally found, the
expression parser now goes hunting for it in all modules
(in the appropriate namespace, if applicable).  This means
that forward-declared types that exist in another shared
library will now be resolved correctly.

Added a test case to cover this.  The test case also tests
"frame variable," which does not have this functionality
yet.

llvm-svn: 146204