virtual void
LanguageRuntime::ModulesDidLoad (const ModuleList &module_list);
Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses.
llvm-svn: 235118
Summary: This will get the windows bots going.
Test Plan: Build LLDB on Windows.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8934
llvm-svn: 234527
Summary:
This fixes an issue with GCC generated binaries wherein an expression
with method invocations on std::string variables was failing. Such use
cases are tested in TestSTL (albeit, in a test marked with
@unittest2.expectedFailure because of other reasons).
The reason for this particular failure with GCC is that the generated
DWARF for std::basic_string<...> is incomplete, which makes clang not
to use the alternate mangling scheme. GCC correctly generates the name
of basic_string<...>:
DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >"
It also lists the template parameters of basic_string correctly:
DW_TAG_template_type_parameter
DW_AT_name "_CharT"
DW_AT_type <0x0000009c>
DW_TAG_template_type_parameter
DW_AT_name "_Traits"
DW_AT_type <0x00000609>
DW_TAG_template_type_parameter
DW_AT_name "_Alloc"
DW_AT_type <0x000007fb>
However, it does not list the template parameters of std::char_traits<>.
This makes Clang feel (while parsing the expression) that the string
variable is not actually a basic_string instance, and consequently does
not use the alternate mangling scheme.
Test Plan:
dotest.py -C gcc -p TestSTL
-- See it go past the "for" loop expression successfully.
Reviewers: clayborg, spyffe
Reviewed By: clayborg, spyffe
Subscribers: tberghammer, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8846
llvm-svn: 234522
Plan is to have this initialized on a per-process basis somewhat the same as the ObjC library on module loading, but this commit is simply the foundation work and will be incrementally built upon to add that detection functionality.
Differential Revision: http://reviews.llvm.org/D8896
llvm-svn: 234503
Since ClangASTSource::layoutRecordType() was overriding a virtual
function in the base, this was inadvertently causing a new method
to be introduced rather than an override. To fix this all method
signatures are changed back to taking DenseMaps, and the `override`
keyword is added to make sure this type of error doesn't happen
again.
To keep the original fix intact, which is that fields and bases
must be added in offset order, the ImportOffsetMap() function
now copies the DenseMap into a vector and then sorts the vector
on the value type (e.g. the offset) before iterating over the
sorted vector and inserting the items.
llvm-svn: 233099
Prior to this patch, we would try to synthesize class types by
iterating over a DenseMap of FieldDecls and adding each one to
a CXXRecordDecl. Since a DenseMap doesn't provide a deterministic
ordering of the elements, this would not add the fields in
FieldOffset order, but rather in some random order determined by
the memory layout of the DenseMap.
This patch fixes the issue by changing DenseMaps to vectors. The
ability to lookup a value in the DenseMap was hardly being used,
and where it is sufficient to do a vector lookup.
Differential Revision: http://reviews.llvm.org/D8512
llvm-svn: 233090
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
Also, since most of the time the lack of such information is a serious problem that hinders productive debugging, emit an actual user visible warning when this occurs (once per process)
Fixes rdar://19898507
llvm-svn: 230299
const, there was never a need for lookup_const_result. Now that vestigal
type is gone, so switch LLDB to lookup_result and to use the
DeclContextLookupResult rather than the Const variant.
llvm-svn: 230126
This also hooks up the new C++14 language constant to be treated
the same as the other C++ language constants.
Differential Revision: http://reviews.llvm.org/D7429
llvm-svn: 228386
While there is quite a bit of potential for mishaps due to tagged pointers, and after quite some internal discussion, this seems a saner behavior given how "po" stands for "print OBJECT". The argument being that we should make at least some sensible attempt to print the thing the user passed as-if it was an object
Fixes rdar://19423124
llvm-svn: 226062
Fixed:
1 - try the symbol table symbol for an ObjC ivar and use it if available
2 - fall back to using the runtime data since it is slower to gather via memory read
3 - Fixed our hidden ivars test case to test this to ensure we don't regress
4 - split out a test case in the hidden ivars to cover only the part that was failing so we don't have an expected failure for all of the other content in the test.
<rdar://problem/18882687>
llvm-svn: 224306
Objective-C type in the runtime. This is not actually
true, it's entirely possible to say
@class DoesntExist;
@interface DoesExist {
DoesntExist *whyyyyy;
}
@end
and this code will not only compile but also run. So
this assertion will fire in situations users might
encounter.
I left the assertion enabled in debug mode, because we
could still catch a case we're not aware of (i.e., a
class that we *ought* to have found but where somehow
we mis-parsed the name).
<rdar://problem/19151914>
llvm-svn: 224038
support to LLDB. It includes the following:
- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
DeclVendors instead.
- Provided a few convenience functions on
ClangASTContext to make that easier.
llvm-svn: 223433
runtime. This eliminates potential confusion
when the compiler has to deal with these weird
types later on.
One day I'd like to actually generate the proper
templates, but this is not the day that I write
the parser code to do that.
<rdar://problem/18887634>
llvm-svn: 221658
- A correctness issue: with assertions disabled,
ReadQuotedString would misbehave; and
- A performance issue: BuildType used a long
chain of if()s; I changed that to two switch
statements. That also makes the code much
nicer to step through when debugging it.
llvm-svn: 221651
structures are parsed safely by the Objective-C runtime.
Also made some modifications to the way we parse structs
in the runtime to avoid mis-parsing @ followed by the name
of the next field.
<rdar://problem/18887634>
llvm-svn: 221643
would fail if the class had no ivars.
- Updated use of the RealizeType API by the class
descriptors to use "for_expression" rather than
the misnamed "allow_unknownanytype."
llvm-svn: 220980
to indicate that we're doing stuff for the expression
parser.
- When for_expression is true, look through @s and find
the actual class rather than just returning id.
- Rename BuildObjCObjectType to BuildObjCObjectPointerType
since it's actually returning an object *pointer* type.
llvm-svn: 220979
I don't think on any of the platforms where ObjC matters sizeof(T*) depends on T, so even if we never figured out the pointee type, the pointer type should still be sane
This might also allow some limited inspection where previously none was possible, so a win
llvm-svn: 219540
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
What it does:
- it introduces a concept of EncodingToType to the ObjCLanguageRuntime
The ObjC runtime has a "type encoding" feature that describes types as strings
The EncodingToType is a decoder for that format, making types out of type encoding strings
This feature already existed in some shape as we were using it to create method signatures out of the runtime, but this checkin extends the parser to support the full syntax, and moves things so that more parts of LLDB have access to this decoder
- it splits the ClassDescriptorV2 object to its own file, it was starting to grow too large
- it adds to the ClassDescriptor mechanism a notion of ivar storage; the ObjC runtime vends ivar information as well as method information
While ivar information is not ready for prime type (i.e. we don't want to add it to the runtime generated types for expression evaluator usage), there are potentially useful scenarios in which realizing ivar types could be useful. For now, the ClassDescriptor is going to hold ivar information directly. Existing code already allows describing ivars, this patch hooks those moving parts up so that one can actually ask a ClassDescriptor about ivars for the class it represents
and as a couple minor niceties:
- it makes it possible to retrieve the LLDB ClangASTContext that is associated to a clang::ASTContext
- it extends the ValueObject-to-ClassDescriptor API in the language runtime to deal correctly with base-class hierarchies
llvm-svn: 216026
- First, when logging, be helpful by printing
the real name of the class;
- Second, up the limit for number of classes
from 16k to 128k, and put in an assertion
(and better error handling when not in a
debug configuration) when we cross that
limit the next time.
<rdar://problem/17052976>
llvm-svn: 213218
directly accessing the isa pointer of a class object to get its meta-class, but the isa
pointers are not simple pointers on arm64, so this would cause the stepping to fail.
object_getClass does whatever magic needs doing in this case.
<rdar://problem/17239690>
llvm-svn: 211289
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
