parser.

<rdar://problem/13631469>

llvm-svn: 179304

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

class symbol in the same expression, handle all
of them instead of just the first one.

<rdar://problem/13440133>

llvm-svn: 177794

and the JITted code are managed by a standalone
class that handles memory management itself.

I have removed RecordingMemoryManager and
ProcessDataAllocator, which filled similar roles
and had confusing ownership, with a common class
called IRExecutionUnit.  The IRExecutionUnit
manages all allocations ever made for an expression
and frees them when it goes away.  It also contains
the code generator and can vend the Module for an
expression to other clases.

The end goal here is to make the output of the
expression parser re-usable; that is, to avoid
re-parsing when re-parsing isn't necessary.

I've also cleaned up some code and used weak pointers
in more places.  Please let me know if you see any
leaks; I checked myself as well but I might have
missed a case.

llvm-svn: 177364

Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere.

llvm-svn: 177091

migration in r171366.

I don't know anything about lldb, but a force run of the build bot indicated it
would need this patch. I'll try to watch the build bot to get it green.

llvm-svn: 171374

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

Patch from Matt Kopec!

llvm-svn: 168945

llvm-svn: 168602

variables for guard variables because the current
class or method named contained the letters "GV".

llvm-svn: 167327

llvm-svn: 165808

change in the LLDB target data API.

llvm-svn: 165754

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

llvm-svn: 165396

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

sel_getName() calls are generated for all Objective-C
selectors before static literals are moved to the
static allocation.  This prevents errors of the form

Internal error [IRForTarget]: Couldn't change a static
reference to an Objective-C selector to a dynamic
reference

<rdar://problem/11331906>

llvm-svn: 160887

to returned by expressions, by removing the
__cxa_atexit call that would normally cause these
objects to be destroyed.  This also prevents many
errors of the form

Couldn't rewrite one of the arguments of a function call
error: Couldn't materialize struct: Structure hasn't been laid out yet

<rdar://problem/11309402>

llvm-svn: 160596

Improved the error message when we can find a function in the current program by printing the demangled name.

Also added the ability to create lldb_private::Mangled instances with a ConstString when we already have a ConstString for a mangled or demangled name. Also added the ability to call SetValue with a ConstString and also without a boolean to indicate if the string is mangled where we will now auto-detect if the string is mangled.

llvm-svn: 160450

we write into doesn't already exist.

<rdar://problem/11775508>

llvm-svn: 159700

- On iOS, we select the "apcs-gnu" ABI to match
  what libraries expect.

- Literals are now allocated at their preferred
  alignment, eliminating many alignment crashes.

llvm-svn: 158236

ones, to its own constant pool.  This reflects the fact
that the LLVM code generators for different targets move
floats to their constant pools under varying conditions,
and the JIT cannot (yet) be relied upon to relocate references to
its constant pool correctly.

llvm-svn: 155660

doesn't return a result.  If that expression can't
be run in the current context (for example, if it
uses a function and there is no running process)
then we used to try to destroy the nonexistent
result variable.  We now only destroy the result
variable if we actually made one.

llvm-svn: 155455

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

llvm-svn: 150142

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

an error along with its boolean result.  The
expression parser reports this error if the 
interpreter fails and the expression could not be
run in the target.

llvm-svn: 148870

the name for an external variable in the IR.

llvm-svn: 147178

complete the result type, preventing crashes later.

llvm-svn: 147107

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

pointer to make the result of an expression.  LLDB now
dumps the ivars of the Objective-C object and all of
its parents.  This just required fixing a bug where we
didn't distinguish between Objective-C object pointers
and regular C-style pointers.

Also added a testcase to verify that this continues to
work.

llvm-svn: 146164

add them to a fast lookup map. lldb_private::Symtab now export the following
public typedefs:

namespace lldb_private {

	class Symtab {
		typedef std::vector<uint32_t> IndexCollection;
		typedef UniqueCStringMap<uint32_t> NameToIndexMap;
	};
}

Clients can then find symbols by name and or type and end up with a 
Symtab::IndexCollection that is filled with indexes. These indexes can then
be put into a name to index lookup map and control if the mangled and 
demangled names get added to the map:

bool add_demangled = true;
bool add_mangled = true;
Symtab::NameToIndexMap name_to_index;
symtab->AppendSymbolNamesToMap (indexes, add_demangled, add_mangled, name_to_index).

This can be repeated as many times as needed to get a lookup table that
you are happy with, and then this can be sorted:

name_to_index.Sort();

Now name lookups can be done using a subset of the symbols you extracted from
the symbol table. This is currently being used to extract objective C types
from object files when there is no debug info in SymbolFileSymtab.

Cleaned up how the objective C types were being vended to be more efficient
and fixed some errors in the regular expression that was being used.

llvm-svn: 145777

robust:

- Now a client can specify what kind of symbols
  are needed; notably, this allows looking up
  Objective-C class symbols specifically.

- In the class of symbols being looked up, if
  one is non-NULL and others are NULL, LLDB now
  prefers the non-NULL one.

llvm-svn: 145554

several patches.  These patches fix a problem
where templated types were not being completed the
first time they were used, and fix a variety of
minor issues I discovered while fixing that problem.

One of the previous local patches was resolved in
the most recent Clang, so I removed it.  The others
will be removed in due course.

llvm-svn: 144984

to allow variables in the persistent variable store to know
how to complete themselves from debug information.  That
fixes a variety of bugs during dematerialization of 
expression results and also makes persistent variable and
result variables ($foo, $4, ...) more useful.

I have also added logging improvements that make it much
easier to figure out how types are moving from place to 
place, and made some checking a little more aggressive.

The commit includes patches to Clang which are currently being
integrated into Clang proper; once these fixes are in Clang
top-of-tree, these patches will be removed.  The patches don't
fix API; rather, they fix some internal bugs in Clang's 
ASTImporter that were exposed when LLDB was moving types from
place to place multiple times.

llvm-svn: 144969

types.  First, I added handling for the memset intrinsic
in the IR, which is used to zero out the returned struct.
Second, I fixed the object-checking instrumentation
to objc_msgSend_stret, and generally tightened up how
the object-checking functions get inserted.

llvm-svn: 144741

would occasionally try to resolve the placeholder
variable used for static data allocation.

llvm-svn: 144677

correctly, and added a testcase to check that it works.

The main problem here is that Objective-C class method
selectors are external references stored in a special
data structure in the LLVM IR module for an expression.
I just had to extract them and ensure that the real
class object locations were properly resolved.

llvm-svn: 143520

the expression makes it to the JIT, and made some
logging only appear in verbose mode.

llvm-svn: 143467

detecting Objective-C method calls because the
"lldb.call.realName" metadata was no longer
being correctly installed.  I fixed this problem.

llvm-svn: 143371

parser.  Now expression like the following work as
expected:

-
(lldb) expr struct { int a; int b; } $blah = { 10, 20 }
<no result>
(lldb) expr $blah
(<anonymous struct at Parse:6:5>) $blah = {
  (int) a = 10
  (int) b = 20
}
-

Now the IRForTarget subsystem knows how to handle
static initializers of various composite types.

Also removed an unnecessary parameter from
ClangExpressionDeclMap::GetFunctionInfo.

llvm-svn: 142936

classes in the expression parser.

llvm-svn: 142717

of arbitrary pointers, allowing direct dereferences
of literal addresses.  Also disabled special-cased
generation of certain expression results (especially
casts), substituting the IR interpreter.

llvm-svn: 142638