"self" when those pointers are in registers.
Previously in this case the IRInterpreter would
handle them just as if the user had typed in
"$rdi", which isn't safe because $rdi is passed
in through the argument struct.

Now we correctly break out all three cases (i.e.,
normal variables in registers, $reg, and this/self),
and handle them in a way that's a little bit easier
to read and change.

This results in more accurate printing of "this" and
"self" pointers all around.  I have strengthened the
optimized-code test case for Objective-C to ensure
that we catch regressions in this area reliably in
the future.

<rdar://problem/12693963>

llvm-svn: 169924

- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code

Patch by Matt Kopec!

llvm-svn: 169645

Now that we set ThreadPlanCallFunction to private in the constructor, it is confusing that we set it
again in client code after creating the plans.  So remove those unnecessary calls.

llvm-svn: 169625

of the "self"/"this" pointer for the current stack
frame before wrapping expressions in C++ or
Objective-C methods.  This works around bad debug
info where the compiler emits a "this" or "self"
but doesn't give any way to find its location.

<rdar://problem/12809985>

llvm-svn: 169461

- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)

Patch by Matt Kopec!

llvm-svn: 169341

interpreter.

<rdar://problem/12657742>

llvm-svn: 169063

whether the current frame is in a C++/Objective-C
class or instance method.

llvm-svn: 169062

- 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

Allow the expression parser to see more than just data symbols. We now accept any symbol that has an address. We take precautions to only accept symbols by their mangled or demangled names only if the demangled name was not synthesized. If the demangled name is synthesized, then we now mark symbols accordingly and only compare against the mangled original name. 

llvm-svn: 168668

llvm-svn: 168602

llvm-svn: 168204

made in upstream llvm (r168114)

llvm-svn: 168184

expressions that refer to ivars will not work because Clang
emits IR that refers to them to get the ivar offsets. 
However, it is possible to search the runtime for these values.

I have added support for reading the relevant tables to the
Objective-C runtime, and extended ClangExpressionDeclMap to
query that information if and only if it doesn't find the symbols
in the binary.

Also added a testcase.

<rdar://problem/12628122>

llvm-svn: 168018

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

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

llvm-svn: 167327

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

llvm-svn: 167168

the containing class so that direct ivar access will work in the expression parser.

<rdar://problem/9797999>

llvm-svn: 167061

The attached patch adds eValueTypeVector to lldb_private::Value.  The nested struct Vector is patterned after RegisterValue::m_data.buffer.  This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue.  Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
 
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py.  In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully.  On the other hand, the output is glaringly empty:
    runCmd: expr $xmm0
    output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
    Expecting sub string: vector_type
    Matched

llvm-svn: 167033

This patch switches support on Linux from JIT to MCJIT.

llvm-svn: 167026

so it could hold this information, and then used it to look up unfound names in the object pointer
if it exists.  This gets "frame var" to work for unqualified references to ivars captured in blocks.
But the expression parser is ignoring this information still.

llvm-svn: 166860

Cleanup some variable names to indicate auto pointers and also manager the llvm::Module memory more correctly.

llvm-svn: 166598

the expression parser (also wchar_t) and added a
test case.

llvm-svn: 166131

the SB API's that evaluate expressions.

<rdar://problem/12457211>

llvm-svn: 166062

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

enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing

        Mutex::Locker(m_map_mutex);

This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately.  Instead,

        Mutex::Locker locker(m_map_mutex);

does what is intended.  For some reason -Wshadow happened to
highlight these as shadowed variables.

I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>

llvm-svn: 165269

llvm-svn: 164572

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

llvm-svn: 164327

Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification.

llvm-svn: 164148

Making ClangExpression hold on to a WP to the Process instead of a SP. This fix should enable us to have per-process maps of ClangExpressions without fear of keeping the process alive forever

llvm-svn: 164082

them in one place rather than having them replicated
across all the potential function wrappers.

<rdar://problem/12293880>

llvm-svn: 163857

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

llvm-svn: 163641

which can conflict with accurate crash reporting
in multithreaded contexts.

llvm-svn: 163282