Reverting because Xcode requires this to be handled elsewhere.
The global variable list gets constructed using the SBAPI
This reverts commit de10c1a824405833a0f49b22e7fa3f32a1393cc3.
This reverts commit 19128792e2aa320c1a149f7f93638cbd7f3c83c6.
As pointed out in https://reviews.llvm.org/D143652 this implementation
doesn't quite work for subobject constructors/destructors because DWARF
can map multiple definitions of a ctor/dtor to the same specification DIE.
With the current implementation we would pick the first definition we
find and use that linkage name which means we can sometimes pick the
wrong dtor/ctor and fail to execute a valid expression.
Differential Revision: https://reviews.llvm.org/D143652
This relands the commit previously reverted in
`d2cc2c5610ffa78736aa99512bc85a85417efb0a` due to failures on Linux
when debugging split-debug-info enabled executables.
The problem was we called `SymbolFileDWARF::FindFunctions` directly
instead of `Module::FindFunctions` which resulted in a nullptr
dereference because the backing `SymbolFileDWARFDwo` didn't have
an index attached to it. The relanded version calls `Module::FindFunctions`
instead.
Differential Revision: https://reviews.llvm.org/D143652
**Summary**
This patch addresses the case where we have a `DW_AT_external`
subprogram for a constructor (and/or destructor) that doesn't carry
a `DW_AT_linkage_name` attribute. The corresponding DIE(s) that
represent the definition will have a linkage name, but if the name
contains constructs that LLDBs fallback mechanism for guessing mangled
names to resolve external symbols doesn't support (e.g., abi-tags)
then we end up failing to resolve the function call.
We address this by trying to find the linkage name before we create
the constructor/destructor decl, which will get attached using
an `AsmLabelAttr` to make symbol resolution easier.
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D143652
Set compiler_versions on these tests, as they fail if tested on lower compiler
versions versions.
Differential Revision: https://reviews.llvm.org/D142513
In API tests, replace use of the `p` alias with the `expression` command.
To avoid conflating tests of the alias with tests of the expression command,
this patch canonicalizes to the use `expression`.
Differential Revision: https://reviews.llvm.org/D141539
Otherwise we may be inserting a decl into a DeclContext that's not fully defined yet.
This simplifies/removes some clang AST node creation code. Instead, use
clang::printTemplateArgumentList().
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D142413
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 cc0b5ebf7fc8, 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
