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
uninitialized memory, to getTrivialTypeSourceInfo,
which initializes its memory, when creating trivial
TypeSourceInfos.
<rdar://problem/13332253>
llvm-svn: 176899
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
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
up variables in the current stack frame to avoid
mutual recursion between the expression parser
and the synthetic child providers. Variables
should only be looked up in a very simple way,
using no synthetic anything.
<rdar://problem/13173454>
llvm-svn: 174947
support reporting "this" as a templated class. The
expression parser wraps expressions in C++ methods
as methods with the signature
$__lldb_class::$__lldb_expr(...)
and previously responded to clang's queries about
$__lldb_class with the type of *this. This didn't
work if *this was a ClassTemplateSpecializationDecl
because ClassTemplateSpecializationDecls can't be
the result of simple name queries.
Instead what we do now is respond that $__lldb_class
is a typedef and that the target of the typedef is
the (potentially templated) type of *this. That is
much more robust.
Thanks to John McCall for key insights.
<rdar://problem/10987183>
llvm-svn: 174153
in an Objective-C class method. Before, errors
of the form
error: cannot find interface declaration for '$__lldb_objc_class'
would appear when running any expression when
the current frame is a block that captures 'self'
from an Objective-C class method.
<rdar://problem/12905561>
llvm-svn: 172880
DW_AT_const_value instead of a location. Also
added a testcase covering "frame variable," "expr"
using the IR interpreter, and "expr" using the
LLVM JIT.
<rdar://problem/12978195>
llvm-svn: 172848
handling multiple clients. However, occasionally an
expression must be run in the service of another
expression, and in this case two parsers need to access
the same list of persistent variables.
To allow this, persistent variables now provide state
for multiple parsers, and parsers must allocate, access,
and deallocate this state by providing their own ID
(at the moment, simply the value of the "this" pointer).
<rdar://problem/12914539>
llvm-svn: 172573
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
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
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
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
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
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
Objective-C method names when looking for functions
in the top level or a namespace. Method names should
only be found via FindExternalLexicalDecls.
<rdar://problem/11711679>
llvm-svn: 160907
Fixed an issue that could cause circular type parsing that will assert and kill LLDB.
Prior to this fix the DWARF parser would always create class types and not start their definitions (for both C++ and ObjC classes) until we were asked to complete the class later. When we had cases like:
class A
{
class B
{
};
};
We would alway try to complete A before specifying "A" as the decl context for B. Turns out we can just start the definition and still not complete the class since we can check the TagDecl::isCompleteDefinition() function. This only works for C++ types. This means we will not be pulling in the full definition of parent classes all the time and should help with our memory consumption and also reduce the amount of debug info we have to parse.
I also reduced redundant code that was checking in a lldb::clang_type_t was a possible C++ dynamic type since it was still completing the type, just to see if it was dynamic. This was fixed in another function that was checking for a type being dynamic as an ObjC or a C++ type, but there was dedicated fucntion for C++ that we missed.
llvm-svn: 153713
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
This takes two important changes:
- Calling blocks is now supported. You need to
cast their return values, but that works fine.
- We now can correctly run JIT-compiled
expressions that use floating-point numbers.
Also, we have taken a fix that allows us to
ignore access control in Objective-C as in C++.
llvm-svn: 152286
This fix really needed to happen as a previous fix I had submitted for
calculating symbol sizes made many symbols appear to have zero size since
the function that was calculating the symbol size was calling another function
that would cause the calculation to happen again. This resulted in some symbols
having zero size when they shouldn't. This could then cause infinite stack
traces and many other side affects.
llvm-svn: 152244
JIT when printing the values of registers (e.g.,
"expr $pc"). Now the expression parser can do this
in the IR interpreter without running code in the
inferior process.
llvm-svn: 150554
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
Greg Clayton