The provided test case was crashing because of confusion attempting to find types for `ns::Foo` under -gsimple-template-names. (This looks broken normally because it's attempting to find `ns::Foo` rather than `ns::Foo<T>`)
Looking up types can't give false positives, as opposed to looking up functions as mentioned in https://reviews.llvm.org/D137098.
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D140240
The original code always set the m_live_address of children of the ValueObjects that
use ValueObjectConstResultImpl backends to the parent m_live_address + child_byte_offset.
That is correct for structure types, but wrong for pointer types, since m_live_address
for a pointer type is the address of the storage for the pointer, not of the pointee.
Also added a test which was failing before this patch.
Without checking template parameters, we would sometimes lookup the
wrong type definition for a type declaration because different
instantiations of the same template class had the same debug info name.
The added GetForwardDeclarationDIETemplateParams() shouldn't need a
cache because we'll cache the results of the declaration -> definition
lookup anyway. (DWARFASTParserClang::ParseStructureLikeDIE()
is_forward_declaration branch)
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D138834
D127284 introduced a new language option which is not benign from modules
perspective. Before this patch lldb would set up the compiler invocation and
later enable incremental processing. Post-D127284 this does not work because
the option causes a module hash mismatch for implicit modules.
In addition, D127284 enables parsing statements on the global scope if
incremental processing is on and thus `syntax_error_for_lldb_to_find` was
rightfully not recognized as a declaration and is considered a statement
which produces a slightly different diagnostic.
Thanks to Michael Buch for the help in understanding this issue. This patch
should appease the lldb bots.
More discussion available at: https://reviews.llvm.org/D127284
DWARFExpression::Evaluate will convert DW_OP_addr addresses in
a DWARF expression into load addresses on the expression stack
when there is a StackFrame in the ExecutionContext, this from
a change in 2018 in https://reviews.llvm.org/D46362. At the
time this was handling a case that came up in swift programs,
and is no longer necessary. I generalized this conversion to
a load address when a Target is available in
https://reviews.llvm.org/D137682 to make a test case possible;
this change broke a use case that Ted reported.
This change removes my test case, and removes this conversion
of a DW_OP_addr into a load address in some instances.
Differential Revision: https://reviews.llvm.org/D139226
After D134378, we started seeing crashes with incomplete types (in the
context of shared libraries).
When trying to print a `std::vector<int> &` with only debug info for a
declaration, we now try to use the formatter after D134378. With an
incomplete type, this somehow goes into infinite recursion with the
frames
```
lldb_private::ValueObject::Dereference
lldb_private::ValueObjectSynthetic::CreateSynthFilter
lldb_private::ValueObjectSynthetic::ValueObjectSynthetic
lldb_private::ValueObject::CalculateSyntheticValue
lldb_private::ValueObject::HasSyntheticValue
```
This has to do with `FrontEndWantsDereference` that some STL formatters
set, causing recursion between the formatter (which tries to dereference),
and dereferencing (which wants to know if there's a formatter to avoid dereferencing).
The reason this only started appearing after D134378 was because
previously with incomplete types, for names with `<`, lldb would attempt
to parse template parameter DIEs, which were empty, then create an empty
`ClassTemplateSpecializationDecl` which overrode the name used to lookup
a formatter in `FormattersMatchData()` to not include template
parameters (e.g. `std::vector<> &`). After D134378 we don't create a
`ClassTemplateSpecializationDecl` when there are no template parameters
and the name to lookup a formatter is the original name (e.g.
`std::vector<int> &`).
The code to try harder with incomplete child compiler types was added in
D79554 for ObjC purposes.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D137983
Followup to D134378.
With PrintingPolicy::SuppressScope, we'd also not print the scope in template params. The intention was only to skip the scope for the class because we expect template params to be fully qualified when comparing them for simple template names.
Instead, use `NamedDecl::getNameForDiagnostic` if we're dealing with a tag, which is what we actually use when emitting debug info in clang. That already has an option to suppress the scope on the base name.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137583
When we cannot allocate memory in the inferior process, the IR
interpreter's IRMemoryMap::FindSpace will create an lldb local
buffer and assign it an address range in the inferior address
space. When the interpreter sees an address in that range, it
will read/write from the local buffer instead of the target. If
this magic address overlaps with actual data in the target, the
target cannot be accessed through expressions.
Instead of using a high memory address that is validly addressable,
this patch uses an address that cannot be accessed on 64-bit systems
that don't actually use all 64 bits of the virtual address.
Differential Revision: https://reviews.llvm.org/D137682
rdar://96248287
**Summary**
The public lldb matrix bot is failing for tests compiled with clang-9, clang-11, clang-13.
This patch addresses these failures by evaluating the enum case that
doesn't cause malformed DWARF in older version of clang.
There was no particular reason we had to use `true` enum case
to reproduce the bug in #58383, so simply switch to use `false`
to get all bots passing again.
**Details**
In older versions of clang, the following snippet:
```
enum EnumBool : bool {
enum_bool_case1 = false,
enum_bool_case2 = true,
};
struct A {
const static EnumBool enum_bool_val = enum_bool_case2;
};
```
…results in following DWARF:
```
0x00000052: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("A")
DW_AT_byte_size (0x01)
DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (6)
0x0000005b: DW_TAG_member
DW_AT_name ("enum_bool_val")
DW_AT_type (0x0000000000000068 "const EnumBool")
DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (7)
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (-1)
```
Note the `DW_AT_const_value == -1`
When evaluating `A::enum_bool_val` in the lldb we get:
```
(lldb) p A::enum_bool_val
error: expression failed to parse:
error: Couldn't lookup symbols:
__ZN1A13enum_bool_valE
```
Enabling the DWARF logs we see:
```
(arm64) clang-13.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 0x00000068, decl_ctx = 0x136ac1e30 (die 0x0000000b)) DW_TAG_const_type name = '(null)')
Failed to add const value to variable A::enum_bool_val: Can't store unsigned value 18446744073709551615 in integer with 1 bits.
```
This occurs because a boolean enum is considered an unsigned integer
type, but we try to initialize it with a `-1`.
**Testing**
- Confirmed locally that top-of-tree lldb correctly
evaluates the previously failing expression when
the test program is compiled with clang-13
Differential Revision: https://reviews.llvm.org/D137793
Undoes a lot of the code added in D135169 to piggyback off of the enum logic in `TypeSystemClang::SetIntegerInitializerForVariable()`.
Fixes#58383.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D137045
See https://discourse.llvm.org/t/dwarf-using-simplified-template-names/58417 for background on simplified template names.
lldb doesn't work with simplified template names because it uses DW_AT_name which doesn't contain template parameters under simplified template names.
Two major changes are required to make lldb work with simplified template names.
1) When building clang ASTs for struct-like dies, we use the name as a cache key. To distinguish between different instantiations of a template class, we need to add in the template parameters.
2) When looking up types, if the requested type name contains '<' and we didn't initially find any types from the index searching the name, strip the template parameters and search the index, then filter out results with non-matching template parameters. This takes advantage of the clang AST's ability to print full names rather than doing it by ourself.
An alternative is to fix up the names in the index to contain the fully qualified name, but that doesn't respect .debug_names.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D134378
The test TestObjCDirectMethods loads the Objective C runtime, which
doesn't work well with custom a libcxx, resulting in two copies of the
standard library being loaded at runtime.
Like what was done for `TestObjCExceptions`, this commit forces the
usage of the system's library instead. The minimum required Clang
version is set to the oldest Clang that can compile the libraries
available in the lldb-matrix bots.
Differential Revision: https://reviews.llvm.org/D136600
Currently, SymbolFileDWARFDebugMap works on the assumption that there is
only one compile unit per object file. This patch documents this
limitation (when using the general SymbolFile API), and allows users of
the concrete SymbolFileDWARFDebugMap class to find out about these extra
compile units.
Differential Revision: https://reviews.llvm.org/D136114
Previously we had a bit of a mix of "signed char" "unsigned char" and
"char".
This adds seperate min and max checks for all three types.
Depends on D135170
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D135352
As with static bool for whatever reason printing them on their own
worked fine but wasn't handled when you printed the whole type.
I don't see a good way to test this from clang's side so our existing
tests will have to do.
We can now print all of the struct "A", so there's no need for a separate
one for static bool testing. I've not checked the output, just that it
succeeds. This saves us having to handle different min/max between systems.
Depends on D135169
Reviewed By: aeubanks, shafik
Differential Revision: https://reviews.llvm.org/D135170
Fixes#58135
Somehow lldb was able to print the member on its own but when we try
to print the whole type found by "image lookup -t" lldb would crash.
This is because we'd encoded the initial value of the member as an integer.
Which isn't the end of the world because bool is integral for C++.
However, clang has a special AST node to handle literal bool and it
expected us to use that instead.
This adds a new codepath to handle static bool which uses cxxBoolLiteralExpr
and we get the member printed as you'd expect.
For testing I added a struct with just the bool because trying to print
all of "A" crashes as well. Presumably because one of the other member's
types isn't handled properly either.
So for now I just added the bool case, we can merge it with A later.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D135169
Currently funciton lookup in the expression evaluator
fails to disambiguate member functions the are overloaded
on lvalue/rvalue reference-qualifiers. This happens because
we unconditionally set a `FunctionPrototype`s
`ExtProtoInfo::RefQualifier` to `RQ_None`. We lose
the ref-qualifiers in the synthesized AST and `clang::Sema`
fails to pick a correct overload candidate.
DWARF emits information about a function's ref-qualifiers
in the form of a boolean `DW_AT_rvalue_reference` (for rvalues)
and `DW_AT_reference` (for lvalues).
This patch sets the `FunctionPrototype::ExtProtoInfo::RefQualifier`
based on the DWARF attributes above.
**Testing**
* Added API test
llvm/llvm-project issue #57866
Differential Revision: https://reviews.llvm.org/D134661
Since we don't compile with `gmodules` implicitly via
debug-info test replication, we should mark all implicit
`gmodules` tests with the appropriate category so the API
tests get actually run as intended.
Differential Revision: https://reviews.llvm.org/D134574
The coroutine tests require a standard library implementation of
coroutines, which was only made available some time _after_ Clang 13.
The first such Clang tested by the LLDB matrix bot is 15.0.1
The TestObjCExceptions test forces the use of the system's libcxx. For
the lldb matrix bot, the first Clang version compatible with the bot's
libraries is 13.0.
Differential Revision: https://reviews.llvm.org/D134645
The uncached lookup is mainly used in the ASTImporter/LLDB code-path
where we're not allowed to load from external storage. When importing
a FieldDecl with a DeclContext that had no external visible storage
(but came from a Clang module or PCH) the above call to `lookup(Name)`
the regular `DeclContext::lookup` fails because:
1. `DeclContext::buildLookup` doesn't set `LookupPtr` for decls
that came from a module
2. LLDB doesn't use the `SharedImporterState`
In such a case we would never continue with the "slow" path of iterating
through the decl chain on the DeclContext. In some cases this means that
ASTNodeImporter::VisitFieldDecl ends up importing a decl into the
DeclContext a second time.
The patch removes the short-circuit in the case where we don't find
any decls via the regular lookup.
**Tests**
* Un-skip the failing LLDB API tests
Differential Revision: https://reviews.llvm.org/D133945
The problem here is that the ASTImporter adds
the template class member FieldDecl to
the DeclContext twice. This happens because
we don't construct a `LookupPtr` for decls
that originate from modules and thus the
ASTImporter never realizes that the FieldDecl
has already been imported. These duplicate
decls then break the assumption of the LayoutBuilder
which expects only a single member decl to
exist.
The test will be fixed by a follow-up revision
and is thus skipped for now.
Differential Revision: https://reviews.llvm.org/D133944
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
Remove the test override of `target.prefer-dynamic-value`.
Previously, the lldb default was `no-dynamic-values`. In rG9aa7e8e9ffbe (in
2015), the default was changed to `no-run-target`, but at that time the tests
were changed to be run with `no-dynamic-value`. I don't know the reasons for
not changing the tests, perhaps to avoid determining which tests to change, and
what about them to change.
Because `no-run-target` is the lldb default, I think it makes sense to make it
the test default too. It puts the test config closer to what's used in
practice.
This change removes the `target.prefer-dynamic-value` override, and for those
tests that failed, they have been updated to explicitly use
`no-dynamic-values`. Future changes could update these tests to use dynamic
values too, or they can be left as is to exercise non-dynamic typing.
Differential Revision: https://reviews.llvm.org/D132382
This check was put in place to prevent static functions
from translation units outside the one that the current
expression is evaluated from taking precedence over functions
in the global namespace. However, this is really a different
bug. LLDB lumps functions from all CUs into a single AST and
ends up picking the file-static even when C++ context rules
wouldn't allow that to happen.
This patch removes the check so we apply the AsmLabel to all
FunctionDecls we create from DWARF if we have a linkage name
available. This makes the code-path easier to reason about and
allows calling static functions in contexts where we previously
would've chosen the wrong function.
We also flip the XFAILs in the API test to reflect what effect
this change has.
**Testing**
* Fixed API tests and added XFAIL
Differential Revision: https://reviews.llvm.org/D132231
This will be useful in preparation for some reshuffling
of assertions in this file since we won't have to
adjust the persitent variable names during the process.
sed commands:
```
s/expect("expr -- /expect_expr("/g
s/startstr="(int) [$0-9]* = /result_type="int", result_value="/g
```
**Testing**
* API tests still pass
Differential Revision: https://reviews.llvm.org/D132271
This test fails for Clang versions < 14.0 for `dsym` variants.
`dsymutil` strips debug info for classes with only static members.
Thus move the failing assertions into the XFAIL test case.
Differential Revision: https://reviews.llvm.org/D132004
When resolving symbols during IR execution, lldb makes a last effort attempt
to resolve external symbols from object files by approximate name matching.
It currently uses `CPlusPlusNameParser` to parse the demangled function name
and arguments for the unresolved symbol and its candidates. However, this
hand-rolled C++ parser doesn’t support ABI tags which, depending on the demangler,
get demangled into `[abi:tag]`. This lack of parsing support causes lldb to never
consider a candidate mangled function name that has ABI tags.
The issue reproduces by calling an ABI-tagged template function from the
expression evaluator. This is particularly problematic with the recent
addition of ABI tags to numerous libcxx APIs.
The issue stems from the fact that `clang::CodeGen` emits function
function calls using the mangled name inferred from the `FunctionDecl`
LLDB constructs from DWARF. Debug info often lacks information for
us to construct a perfect FunctionDecl resulting in subtle mangled
name inaccuracies.
This patch side-steps the problem of inaccurate `FunctionDecl`s by
attaching an `asm()` label to each `FunctionDecl` LLDB creates from DWARF.
`clang::CodeGen` consults this label to get the mangled name as one of
the first courses of action when emitting a function call.
LLDB already does this for C++ member functions as of
[675767a591](https://reviews.llvm.org/D40283)
**Testing**
* Added API tests
Differential Revision: https://reviews.llvm.org/D131974
Patch sets ARM cpu, before compiling JIT code. This enables FastISel for armv6 and higher CPUs and allows using hardware FPU
~~~
OS Laboratory. Huawei RRI. Saint-Petersburg
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131783
When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.
This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.
A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.
The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.
The original patch was written by Fred Riss almost 4 years ago.
Differential revision: https://reviews.llvm.org/D51387
When targeting macOS Ventura, ld64 will use authenticated fixups for
x86_64 as well as arm64 (where that has always been the case). This
results in test failures when using an Xcode 14 toolchain on an Intel
mac running macOS Ventura:
Failed Tests (3):
lldb-api :: commands/target/basic/TestTargetCommand.py
lldb-api :: lang/c/global_variables/TestGlobalVariables.py
lldb-api :: lang/cpp/char8_t/TestCxxChar8_t.py
Rather than trying to come up with a sophisticated decorator based off
the deployment target, I marked them all as skipped with a comment
explaining why.
Differential revision: https://reviews.llvm.org/D131741
