LLDB evaluates some utility expression to update the Objective-C class list that
ends up calling function such as `free` or `objc_copyRealizedClassList_nolock`.
This adds a test that just tries to define our own bogus version of
`objc_copyRealizedClassList_nolock`. It just tests that LLDB doesn't crash as we
currently don't have a way to tell LLDB to look for the function in a specific
library.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107778
We recently had an issue where a user declared a `Class::free` function which
then got picked up by accident by the expression evaluator when calling
`::free`. This was due to a too lax filter in the DWARFIndex (which was fixed by
https://reviews.llvm.org/D73191 ). This broke the Objective-C utility expression
that is trying to update the Objective-C class list (which is calling `:;free`).
This adds a regression test for situations where we have a bunch of functions
defined that share the name of the global functions that this utility function
calls. None of them are actually conflicting with the global functions we are
trying to call (they are all in namespaces, objects or classes).
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107776
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
This reverts commit 34d78b6a67.
This breaks build bots witha missing file:
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10: fatal error: 'objc/runtime.h' file not found
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
Summary:
In the spirit of https://reviews.llvm.org/D70846, we only return functions with
matching mangled name from Apple/DebugNamesDWARFIndex::GetFunction if
eFunctionNameTypeFull is requested.
This speeds up lookup in the presence of large amount of class methods of the
same name (a typical examples would be constructors of templates with many
instantiations or overloaded operators).
Reviewers: labath, teemperor
Reviewed By: labath, teemperor
Subscribers: aprantl, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73191
D105471 fixes the way we assign sizes to empty structs in C mode. Instead of
just giving them a size 0, we instead use the size we get from DWARF if possible.
After landing D105471 the TestStructTypes test started failing on Windows. The
tests checked that the size of an empty C struct is 0 while the size LLDB now
reports is 4 bytes. It turns out that 4 bytes are the actual size Clang is using
for C structs with the MicrosoftRecordLayoutBuilder. The commit that introduced
that behaviour is 00a061dccc.
This patch removes that specific check from TestStructTypes. Note that D105471
added a series of tests that already cover this case (and the added checks
automatically adjust to whatever size the target compiler chooses for empty
structs).
C doesn't allow empty structs but Clang/GCC support them and give them a size of 0.
LLDB implements this by checking the tag kind and if it's `DW_TAG_structure_type` then
we give it a size of 0 via an empty external RecordLayout. This is done because our
internal TypeSystem is always in C++ mode (which means we would give them a size
of 1).
The current check for when we have this special case is currently too lax as types with
`DW_TAG_structure_type` can also occur in C++ with types defined using the `struct`
keyword. This means that in a C++ program with `struct Empty{};`, LLDB would return
`0` for `sizeof(Empty)` even though the correct size is 1.
This patch removes this special case and replaces it with a generic approach that just
assigns empty structs the byte_size as specified in DWARF. The GCC/Clang special
case is handles as they both emit an explicit `DW_AT_byte_size` of 0. And if another
compiler decides to use a different byte size for this case then this should also be
handled by the same code as long as that information is provided via `DW_AT_byte_size`.
Reviewed By: werat, shafik
Differential Revision: https://reviews.llvm.org/D105471
This test is using -gpubnames which is only available since Clang 8. The
original Clang 7 requirement was based on the availability of
-accel-tables=Dwarf (which the test initially used before being changed to
-gpubnames in commit 15a6df52ef ).
DWARF doesn't describe templates itself but only actual template instantiations.
Because of that LLDB has to infer the parameters of the class template
declarations from the actual instantiations when creating the internal Clang AST
from debug info
Because there is no dedicated DIE for the class template, LLDB also creates the
`ClassTemplateDecl` implicitly when parsing a template instantiation. To avoid
creating one ClassTemplateDecls for every instantiation,
`TypeSystemClang::CreateClassTemplateDecl` will check if there is already a
`ClassTemplateDecl` in the requested `DeclContext` and will reuse a found
fitting declaration.
The logic that checks if a found class template fits to an instantiation is
currently just comparing the name of the template. So right now we map
`template<typename T> struct S;` to an instantiation with the values `S<1, 2,
3>` even though they clearly don't belong together.
This causes crashes later on when for example the Itanium mangler's
`TemplateArgManglingInfo::needExactType` method tries to find fitting the class
template parameter that fits to an instantiation value. In the example above it
will try to find the parameter for the value `2` but will just trigger a
boundary check when retrieving the parameter with index 1 from the class
template.
There are two ways we can end up with an instantiation that doesn't fit to a
class template with the same name:
1. We have two TUs with two templates that have the same name and internal
linkage.
2. A forward declared template instantiation is emitted by GCC and Clang
without an empty list of parameter values.
This patch makes the check for whether a class template declaration can be
reused more sophisticated by also comparing whether the parameter values can fit
to the found class template. If we can't find a fitting class template we
justcreate a second class template with the fitting parameters.
Fixes rdar://76592821
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D100662
Both tests are passing for GCC>8 on Linux so let's mark them as passing.
TestCPPAuto was originally disabled due to "an problem with debug info generation"
in ea35dbeff2 .
TestClassTemplateParameterPack was disabled without explanation in
0f01fb39e3 .
This reverts commit 00764c36ed and the
follow up d2223c7a49.
The original patch broke that one could use static member variables while
inside a static member functions without having a running target. It seems that
LLDB currently requires that static variables are only found via the global
variable lookup so that they can get materialized and mapped to the argument
struct of the expression.
After 00764c36ed static variables of the current
class could be found via Clang's lookup which LLDB isn't observing. This
resulting in expressions actually containing these variables as normal
globals that can't be rewritten to a member of the argument struct.
More specifically, in the test TestCPPThis, the expression
`expr --j false -- s_a` is now only passing if we have a runnable target.
I'll revert the patch as the possible fixes aren't trivial and it degrades
the debugging experience more than the issue that the revert patch addressed.
The underlying bug can be reproduced before/after this patch by stopping
in `TestCPPThis` main function and running: `e -j false -- my_a; A<int>::s_a`.
The `my_a` will pull in the `A<int>` class and the second expression will
be resolved by Clang on its own (which causes LLDB to not materialize the
static variable).
Note: A workaround is to just do `::s_a` which will force LLDB to take the global
variable lookup.
When checking for type properties we usually want to strip all kind of type
sugar from the type. For example, sugar like Clang's ElaboratedType or typedefs
rarely influence the fundamental behaviour of a type such as its byte size.
However we always need to preserve type sugar for everything else as it does
matter for users that their variable of type `size_t` instead of `unsigned long`
for example.
This patch fixes one such bug when trying to use the SBValue API to dereference
a type.
Reviewed By: werat, shafik
Differential Revision: https://reviews.llvm.org/D103532
This was originally failed because of llvm.org/pr21765 which describes that
LLDB can't call a debugee's functions, but I removed the (unnecessary)
function call in the rewrite. It seems that the actual bug here is that we
can't lookup static members at all, so let's X-FAIL the test for the right
reason.
Clang adds a Decl in two phases to a DeclContext. First it adds it invisible and
then it makes it visible (which will add it to the lookup data structures). It's
important that we can't do lookups into the DeclContext we are currently adding
the Decl to during this process as once the Decl has been added, any lookup will
automatically build a new lookup map and add the added Decl to it. The second
step would then add the Decl a second time to the lookup which will lead to
weird errors later one. I made adding a Decl twice to a lookup an assertion
error in D84827.
In the first step Clang also does some computations on the added Decl if it's
for example a FieldDecl that is added to a RecordDecl.
One of these computations is checking if the FieldDecl is of a record type
and the record type has a deleted constexpr destructor which will delete
the constexpr destructor of the record that got the FieldDecl.
This can lead to a bug with the way we implement MinimalImport in LLDB
and the following code:
```
struct Outer {
typedef int HookToOuter;
struct NestedClass {
HookToOuter RefToOuter;
} NestedClassMember; // We are adding this.
};
```
1. We just imported `Outer` minimally so far.
2. We are now asked to add `NestedClassMember` as a FieldDecl.
3. We import `NestedClass` minimally.
4. We add `NestedClassMember` and clang does a lookup for a constexpr dtor in
`NestedClass`. `NestedClassMember` hasn't been added to the lookup.
5. The lookup into `NestedClass` will now load the members of `NestedClass`.
6. We try to import the type of `RefToOuter` which will try to import the `HookToOuter` typedef.
7. We import the typedef and while importing we check for conflicts in `Outer` via a lookup.
8. The lookup into `Outer` will cause the invisible `NestedClassMember` to be added to the lookup.
9. We continue normally until we get back to the `addDecl` call in step 2.
10. We now add `NestedClassMember` to the lookup even though we already did that in step 8.
The fix here is disabling the minimal import for RecordTypes from FieldDecls. We
actually already did this, but so far we only force the definition of the type
to be imported *after* we imported the FieldDecl. This just moves that code
*before* we import the FieldDecl so prevent the issue above.
Reviewed By: shafik, aprantl
Differential Revision: https://reviews.llvm.org/D102993
It's not clear why the whole test got disabled, but the linked bug report
has since been fixed and the only part of it that still fails is the test
for the too permissive lookup. This re-enables the test, rewrites it to use
the modern test functions we have and splits the failing part into its
own test that we can skip without disabling the rest.
`bool` is considered to be unsigned according to `std::is_unsigned<bool>::value` (and `Type::GetTypeInfo`). Encoding it as signed int works fine for normal variables and fields, but breaks when reading the values of boolean bitfields. If the field is declared as `bool b : 1` and has a value of `0b1`, the call to `SBValue::GetValueAsSigned()` will return `-1`.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D102685
The test added in D100977 is failing to compile on these platforms. This seems
to be caused by GCC, MSVC and Clang@Windows rejecting the code because
`ToLayout` isn't complete when pointer_to_member_member is declared (even though
that seems to be valid code).
This also reverts the test changes in the lazy-loading test from D100977 as
that failed for the same reason.
At the moment the expression parser doesn't support evaluating expressions in
static member functions and just pretends the expression is evaluated within a
non-member function. This causes that all static members are inaccessible when
doing unqualified name lookup.
This patch adds support for evaluating in static member functions. It
essentially just does the same setup as what LLDB is already doing for
non-static member functions (i.e., wrapping the expression in a fake member
function) with the difference that we now mark the wrapping function as static
(to prevent access to non-static members).
Reviewed By: shafik, jarin
Differential Revision: https://reviews.llvm.org/D81550
When LLDB's DWARF parser is parsing the member DIEs of a struct/class it
currently fully resolves the types of static member variables in a class before
adding the respective `VarDecl` to the record.
For record types fully resolving the type will also parse the member DIEs of the
respective class. The other way of resolving is just 'forward' resolving the type
which will try to load only the minimum amount of information about the type
(for records that would only be the name/kind of the type). Usually we always
resolve types on-demand so it's rarely useful to speculatively fully resolve
them on the first use.
This patch changes makes that we only 'forward' resolve the types of static
members. This solves the fact that LLDB unnecessarily loads debug information
to parse the type if it's maybe not needed later and it also avoids a crash where
the parsed type might in turn reference the surrounding class that is currently
being parsed.
The new test case demonstrates the crash that might happen. The crash happens
with the following steps:
1. We parse class `ToLayout` and it's members.
2. We parse the static class member and fully resolve its type
(`DependsOnParam2<ToLayout>`).
3. That type has a non-static class member `DependsOnParam1<ToLayout>` for which
LLDB will try to calculate the size.
4. The layout (and size)`DependsOnParam1<ToLayout>` turns depends on the
`ToLayout` size/layout.
5. Clang will calculate the record layout/size for `ToLayout` even though we are
currently parsing it and it's missing it's non-static member.
The created is missing the offset for the yet unparsed non-static member. If we
later try to get the offset we end up hitting different asserts. Most common is
the one in `TypeSystemClang::DumpValue` where it checks that the record layout
has offsets for the current FieldDecl.
```
assert(field_idx < record_layout.getFieldCount());
```
Fixed rdar://67910011
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D100180
When referencing `NSObject`, it's enough to import `objc/NSObject.h`. Importing `Foundation` is unnecessary in these cases.
Differential Revision: https://reviews.llvm.org/D99867
Use `@import ObjectiveC` instead of `@import Foundation`, as the former is all
that's needed, and results in fewer clang modules being built.
This results in the following clang modules *not* being built for this test.
ApplicationServices
CFNetwork
ColorSync
CoreFoundation
CoreGraphics
CoreServices
CoreText
DiskArbitration
Dispatch
Foundation
IOKit
ImageIO
Security
XPC
_Builtin_intrinsics
launch
libkern
os_object
os_workgroup
Differential Revision: https://reviews.llvm.org/D99859
This is apparently allowed in Objective-C so we should test this in LLDB.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D99513
This is an LLDB test for the ASTImporter crash that got fixed in D99077.
The test is using Clang modules for the properties as it seems the conflicting
names are not actually correctly handled when generating debug information
(only the first property is emitted and the second one is ignored in the current
clang ToT).
Right now when running `expr --top-level -- void foo() {}`, LLDB just prints a cryptic
`error: Couldn't find $__lldb_expr() in the module` error. The reason for that is
that if we don't have a running process, we try to set our execution policy to always use the
IR interpreter (ExecutionPolicyNever) which works even without a process. However
that code didn't consider the special ExecutionPolicyTopLevel which we use for
top-level expressions. By changing the execution policy to ExecutionPolicyNever,
LLDB thinks we're actually trying to interpret a normal expression inside our
`$__lldb_expr` function and then fails when looking for it.
This just adds an exception for top-level expressions to that code and a bunch of tests.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D91723
Clang emits a warning when accessing an Objective-C getter but not using the result.
This gets triggered when just trying to print a getter value in the expression parser (where
Clang just sees a normal expression like `obj.getter` while parsing).
This patch just disables the warning in the expression parser (similar to what we do with
the C++ equivalent of just accessing a member variable but not doing anything with it).
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D94307
BlockPointerSyntheticFrontEnd does a CopyType which results in it copying the type
back into its own context. This will result in a call to ASTImporterDelegate::setOrigin
with &decl->getASTContext() == origin.ctx this can result in an infinite recursion
later on in ASTImporter since it will attempt to find the decl in its origin which will be itself.
Differential Revision: https://reviews.llvm.org/D96366
Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.
These were mostly done via regex search & replace, with some manual fixes.
Differential Revision: https://reviews.llvm.org/D95813
ObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is now fixed.
Also adding tests for one bit bit-fields of BOOL and unsigned char.
Copy paste error, but the test still built on macOS. Weird.
It failed on debian linux with an error about -fno-limit-debug-info
not being a supported flag??? Not sure how this goof would cause
that error, but let's see if it did...
If they occurred before the constructor that used them, we would refuse to
set the breakpoint because we thought they were crossing function boundaries.
Differential Revision: https://reviews.llvm.org/D94846
Raphael Isemann