When a PDB is loaded through `target symbols add <pdb-path>`, its
`m_objectfile_sp` is an `ObjectFilePDB` instead of `ObjectFilePECOFF`
(the debugged module). In both the native and DIA plugin, some paths
assumed that `m_objectfile_sp` is the debugged module. With this PR,
they go through `m_objfile_sp->GetModule()->GetObjectFile()`.
For the DIA plugin, this lead to an assertion failure
(https://github.com/llvm/llvm-project/issues/169628#issuecomment-3582555277)
and for both plugins, it meant that the symbol table wasn't loaded.
All PDB tests now pass when compiled without DIA on Windows, so they
pass with the native reader.
With this PR, the default reader changes to the native reader.
The plan is to eventually remove the DIA reader (see
https://discourse.llvm.org/t/rfc-removing-the-dia-pdb-plugin-from-lldb/87827
and #114906).
For now, DIA can be used by setting `plugin.symbol-file.pdb.reader` to
`dia` or by setting `LLDB_USE_NATIVE_PDB_READER=0` (mostly undocumented,
but used in tests).
When creating all types in a compilation unit, simple types (~>
primitive and pointer types) that were only used in function arguments
or return types weren't created as LLDB `Type`s.
With this PR, they're created when creating the function/method types.
This makes it possible to run the `SymbolFile/PDB/typedefs.test` with
both plugins.
The `pointers.test` was only run with the DIA plugin. I made the
following changes:
- Remove the check for the function type.
The types of the function are different in the plugins:
```
Native:
Type{0x00010084} , size = 0, compiler_type = 0x00000209aff60060 int
(int) __attribute__((thiscall))
DIA:
Type{0x0000000a} , name = "f", decl = PointerTypeTest.cpp:8,
compiler_type = 0x0000020bc22356c0 int (int) __attribute__((thiscall))
```
In DIA, each function gets its own type with a name and decl. In the
native plugin, only one unnamed type is created per signature. This
matches DWARF.
- The check for the `struct ST` fields was split, because the order of
members and methods is swapped between the plugins. In DIA, the member
is first and in the native plugin the method is first. We still check
that both are in the struct.
- The type names for the local variables are different. The native
plugin includes <code>\`extern "C" main'::\`2'::ST</code> which I added
as an allowed prefix. This comes from the mangled name of the struct
`ST` - `.?AUST@?1??main@@9@`.
- The location of local variables is different. DIA creates one static
location (e.g. `DW_OP_breg6 ESI-52`) whereas the native plugin limits
the location to the block (e.g. `[0x0040100d, 0x00401038): DW_OP_breg6
ESI-52`). This gets printed on a second line and the `location` starts
with `0x00000000:`
- DIA adds a decl for each parameter (and local variable). However, this
information is not contained in the PDB. I'm not sure how DIA calculates
this. It's often wrong and assumes variables are declared earlier. For
example, in this test
([PointerTypeTest.cpp](2b135b9313/lldb/test/Shell/SymbolFile/PDB/Inputs/PointerTypeTest.cpp)),
it assumes that all local variables of `main` are created on line 4. The
native plugin doesn't include this, so I made the check optional.
The test checks that functions have the correct type assigned. Because
of the differences between the two PDB plugins, I split the test.
DIA creates one named `Type` per function and uses identical UIDs for
`Type` and `Function`, whereas native creates one unnamed type per
signature and has different UIDs.
The native test has the same input and checks the same functions.
I also removed the `target-windows` requirement from the test, since it
only uses `lldb-test`.
Relands #149701 which was reverted in
185ae5cdc6
because it broke demangling of Itanium symbols on i386.
The last commit in this PR adds the fix for this (discussed in #160930).
On x86 environments, the prefix of `__cdecl` functions will now be
removed to match DWARF. I opened #161676 to discuss this for the other
calling conventions.
Before, functions created using the NativePDB plugin would not know
about their mangled name. This showed when printing a stacktrace. There,
only the function name was shown. For
https://github.com/llvm/llvm-project/issues/143149, the mangled function
name is required to separate different parts.
This PR adds that name if available.
The Clang AST nodes also take in a mangled name, which was previously
unset. I don't think this unblocks anything further, because Clang can
mangle the function anyway.
If LLDB was built without the DIA SDK and the DIA reader is explicitly
requested (through `LLDB_USE_NATIVE_PDB_READER=0` or `settings set
plugin.symbol-file.pdb.reader dia`), LLDB should print a warning,
because it will use the native reader in any case
(https://github.com/llvm/llvm-project/pull/159769#discussion_r2367316980).
This PR adds the warning and a test when LLDB is not built with the SDK
on Windows. I don't think any builder runs this configuration, as there
are still five failing tests. I tested this locally with and without the
SDK.
This test was failing with the native plugin due to two reasons:
1. The static `C::abc` was printed as `(int) ::C::abc = 123`
2. The order of the base classes of [`C`
(`List::Value`)](b7e4edca3d/lldb/test/Shell/SymbolFile/PDB/Inputs/UdtLayoutTest.cpp (L30))
is different between DIA and the native plugin. I don't know how the
order in the DIA plugin is determined - it prints `B<0>`, `B<1>`,
`B<2>`, `B<3>`, `A`. The native plugin follows the order of the bases in
memory and prints `B<2>`, `B<3>`, `A`, `B<0>`, `B<1>` (last three are
the virtual bases).
<details><summary>Class layout of C</summary>
```
class C size(88):
+---
0 | +--- (base class B<2>)
0 | | {vbptr}
8 | | _a
9. | | _b (bitstart=3,nbits=6)
11 | | _c
| +---
15 | +--- (base class B<3>)
15 | | {vbptr}
23 | | _a
24. | | _b (bitstart=3,nbits=6)
26 | | _c
| +---
| <alignment member> (size=2)
32 | _x
36 | _y
38 | _z
| <alignment member> (size=1)
| <alignment member> (size=2)
+---
+--- (virtual base A)
40 | {vfptr}
48 | U _u
| <alignment member> (size=4)
+---
+--- (virtual base B<0>)
56 | {vbptr}
64 | _a
65. | _b (bitstart=3,nbits=6)
67 | _c
+---
+--- (virtual base B<1>)
71 | {vbptr}
79 | _a
80. | _b (bitstart=3,nbits=6)
82 | _c
+---
```
</details>
I split the tests for the plugins for better readability.
When creating LLDB types from `LF_MODIFIER` records, the type name of
the modified type was used. This didn't include the modifiers
(`const`/`volatile`/`__unaligned`). With this PR, they're included.
The DIA plugin had a test for this. That test also assumed that function
types had a name. I removed that check here, because function/procedure
types themselves in PDB don't have a name:
```
0x1015 | LF_ARGLIST [size = 20, hash = 0xBCB6]
0x0074 (int): `int`
0x1013: `int* __restrict`
0x1014: `int& __restrict`
0x1016 | LF_PROCEDURE [size = 16, hash = 0x3F611]
return type = 0x0003 (void), # args = 3, param list = 0x1015
calling conv = cdecl, options = None
```
I assume DIA gets the name from the function symbol itself. In the
native plugin, that name isn't included and multiple functions with the
same signature will reuse one type, whereas DIA would create a new type
for each function. The
[Shell/SymbolFile/PDB/func-symbols.test](b29c7ded31/lldb/test/Shell/SymbolFile/PDB/func-symbols.test)
also relies on this.
If LLDB is built without the DIA SDK enabled, then the native plugin is
used regardless of `plugin.symbol-file.pdb.reader` or
`LLDB_USE_NATIVE_PDB_READER`. This made the test fail on Windows when
the DIA SDK was disabled
(https://github.com/llvm/llvm-project/issues/114906#issuecomment-3241796062).
This PR changes the requirement for the test from `target-windows` to
`diasdk` (only used in this test).
After parsing blocks in a function, the blocks should be marked as
parsed for them to be dumped (see
[Function::Dump](e6aefbec78/lldb/source/Symbol/Function.cpp (L446-L447))).
As explained in
https://github.com/llvm/llvm-project/issues/114906#issuecomment-3255016266,
this happens (accidentally?) in the DIA plugin when parsing variables,
because it calls `function.GetBlock(can_create=true)` which marks blocks
as parsed. In the native plugin, this was never called, so blocks and
variables were never included in the `lldb-test symbols` output.
The `variables.test` for the DIA plugin tests this. One difference
between the plugins is how they specify the location of local variables.
This causes the output of the native plugin to be two lines per
variable, whereas the DIA plugin has one line:
```
(native):
000002C4B7593020: Variable{0x1c800001}, name = "var_arg1", type = {0000000000000744} 0x000002C4B6CA7900 (int), scope = parameter, location = 0x00000000:
[0x000000014000102c, 0x000000014000103e): DW_OP_breg7 RSP+8
```
```
(DIA):
000002778C827EE0: Variable{0x0000001b}, name = "var_arg1", type = {0000000000000005} 0x000002778C1FBAB0 (int), scope = parameter, decl = VariablesTest.cpp:32, location = DW_OP_breg7 RSP+8
```
In the test, I filtered lines starting with spaces followed by `[0x`, so
we can still use `CHECK-NEXT`.
---
Another difference between the plugins is that DIA marks the `this`
pointer as artificial (equivalent to DWARF). This is done if a
variable's object kind is `ObjectPtr`
([source](ab898f32c6/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp (L1050))).
As far as I know, there isn't anything in the debug info that says "this
variable is the `this` pointer" other than the name/type of a variable
and the type of the function.
To find global variables, `SymbolFileNativePDB` used to search the
globals stream for the name passed to `FindGlobalVariables`. However,
the symbols in the globals stream contain the fully qualified name and
`FindGlobalVariables` only gets the basename. The approach here is
similar to the one for types and functions.
As we already search the globals stream for functions, we can cache the
basenames for global variables there as well.
This makes the `expressions.test` from the DIA PDB plugin pass with the
native one (#114906).
Tag types like stucts or enums didn't have a declaration attached to
them. The source locations are present in the IPI stream in
`LF_UDT_MOD_SRC_LINE` records:
```
0x101F | LF_UDT_MOD_SRC_LINE [size = 18, hash = 0x1C63]
udt = 0x1058, mod = 3, file = 1, line = 0
0x2789 | LF_UDT_MOD_SRC_LINE [size = 18, hash = 0x1E5A]
udt = 0x1253, mod = 35, file = 93, line = 17069
```
The file is an ID in the string table `/names`:
```
ID | String
1 | '\<unknown>'
12 | 'D:\a\_work\1\s\src\ExternalAPIs\WindowsSDKInc\c\Include\10.0.22621.0\um\wingdi.h'
93 | 'D:\a\_work\1\s\src\ExternalAPIs\WindowsSDKInc\c\Include\10.0.22621.0\um\winnt.h'
```
Here, we're not interested in `mod`. This would indicate which module
contributed the UDT.
I was looking at Rustc's PDB and found that it uses `<unknown>` for some
types, so I added a check for that.
This makes two DIA PDB shell tests to work with the native PDB plugin.
---------
Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
Some DIA PDB tests pass with the native plugin already, but didn't test
this. This adds test runs with the native plugin - no functional
changes.
In addition to the x86 calling convention test, there's also
9f102a9004/lldb/test/Shell/SymbolFile/PDB/calling-conventions-arm.test,
but I can't test this.
Initially suggested in
https://github.com/llvm/llvm-project/pull/149305#issuecomment-3113413702
- this PR adds the setting `plugin.symbol-file.pdb.use-native-reader`.
It doesn't remove support for `LLDB_USE_NATIVE_PDB_READER` to allow some
backwards compatibility. This was the suggested way to use the native
reader - changing that would mean users who set this, now use the DIA
reader. The setting has priority over the environment variable, though.
If the default gets flipped on Windows, the environment variable could
probably be removed as well.
This would make it possible to test both native PDB and DIA PDB in the
API tests (see linked PR).
%T has been deprecated for about seven years, mostly because it is not
unique to each test which can lead to races. This patch updates the few
remaining tests in lldb that use %T to not use it (either directly using
files or creating their own temp dir). The eventual goal is to remove
support for %T from llvm-lit given few tests use it and it still has
racey behavior.
This patch errors on the side of creating new temp dirs even when not
strictly necessary to avoid needing to update filenames inside filecheck
matchers.
https://github.com/llvm/llvm-project/pull/149282 changed
the max children depth and that caused one part of the
output to become `{...}`.
The original PR set a higher limit for a different test,
so I'm doing the same here.
This reverts commit 2526d5b1689389da9b194b5ec2878cfb2f4aca93, reapplying
ba14dac481564000339ba22ab867617590184f4c after fixing the conflict with
#117532. The change is that Function::GetAddressRanges now recomputes
the returned value instead of returning the member. This means it now
returns a value instead of a reference type.
This is a follow-up/reimplementation of #115730. While working on that
patch, I did not realize that the correct (discontinuous) set of ranges
is already stored in the block representing the whole function. The
catch -- ranges for this block are only set later, when parsing all of
the blocks of the function.
This patch changes that by populating the function block ranges eagerly
-- from within the Function constructor. This also necessitates a
corresponding change in all of the symbol files -- so that they stop
populating the ranges of that block. This allows us to avoid some
unnecessary work (not parsing the function DW_AT_ranges twice) and also
results in some simplification of the parsing code.
Since the remote Shell test execution feature was added, these tests
should now be disabled on Windows target instead of Windows host.
It should fix failures on
https://lab.llvm.org/staging/#/builders/197/builds/76.
This doesn't parse S_CONSTANT case yet, because I found that the global
variable `std::strong_ordering::equal` is a S_CONSTANT and has type of
LF_STRUCTURE which is not currently handled when creating dwarf
expression for the variable. Left a TODO for it to finish later.
This makes `lldb/test/Shell/SymbolFile/PDB/ast-restore.test` and
`lldb/test/Shell/SymbolFile/PDB/calling-conventions-x86.test` pass on
windows with native pdb plugin only.
Remove lldb-repro which was used to run the test suite against a
reproducer. The corresponding functionality has been removed from LLDB
so there's no need for the tool anymore.
The S_LPROC32_ID and S_GPROC32_ID CodeView Debug Symbols have a flags
field which LLVM has had the values for (in the ProcSymFlags enum) but
has never actually set.
These flags are used by Microsoft-internal tooling that leverages debug
information to do binary analysis.
Modified LLVM to set the correct flags:
- ProcSymFlags::HasOptimizedDebugInfo - always set, as this indicates that
debug info is present for optimized builds (if debug info is not emitted
for optimized builds, then LLVM won't emit a debug symbol at all).
- ProcSymFlags::IsNoReturn and ProcSymFlags::IsNoInline - set if the
function has the NoReturn or NoInline attributes respectively.
- ProcSymFlags::HasFP - set if the function requires a frame pointer (per
TargetFrameLowering::hasFP).
Per discussion in review, XFAIL'ing lldb test until someone working on
lldb has a chance to look at it.
Differential Revision: https://reviews.llvm.org/D148761
In Shell 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`.
See also D141539 which made the same change to API tests.
Differential Revision: https://reviews.llvm.org/D146230
pointers.test started failing again for AArch64 windows after D125509
This patch fixes the test to make it pass on AArch64 windows again.
LLDB AArch64 Windows buildbot running at:
https://lab.llvm.org/staging/#/builders/207
PDB/func-symbols.test was orignally written for 32bit x86, keeping in
mind cdecl and stdcall calling conventions which does name mangling for
example like adding "_" underscore before function name.
This is only x86 specific but purpose of pointers.test is NOT to test
calling convention.
I have made a minor change to make this test pass on Windows/Arm.
This patch renames PDB/calling-conventions.test to calling-conventions-x86.test.
Also restrict it to run only for target-x86*.
This patch also adds a arm specific test PDB/calling-conventions-arm.test which
tests that x86 specifc calling convention decorators are ignored by Arm compiler.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D128678
PDB/pointers.test was orignally written for 32bit x86 keeping in mind
__cdecl and __stdcall calling conventions which does name mangling for
example like adding "_" underscore before function name.
This is only x86 specific but purpose of pointers.test is NOT to test
calling convention.
I am have made a few minor changes to this test which will make it pass
when run on Windows/Arm platform.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D128668
The pdb lldb tests do not work correctly with both the VS2019 and VS2017 toolsets at the moment. This change updates several of the tests to work with both toolsets. Unfortunately, this makes the tests suboptimal for both toolsets, but we can update them to be better for VS2019 once we officially drop VS2017. This change is meant to bridge the gap until the update happens, so that the buildbots can work with either toolset.
Differential Revision: https://reviews.llvm.org/D115482
Constructor homing reduces the amount of class type info that is emitted
by emitting conmplete type info for a class only when a constructor for
that class is emitted.
This will mainly reduce the amount of duplicate debug info in object
files. In Chrome enabling ctor homing decreased total build directory sizes
by about 30%.
It's also expected that some class types (such as unused classes)
will no longer be emitted in the debug info. This is fine, since we wouldn't
expect to need these types when debugging.
In some cases (e.g. libc++, https://reviews.llvm.org/D98750), classes
are used without calling the constructor. Since this is technically
undefined behavior, enabling constructor homing should be fine.
However Clang now has an attribute
`__attribute__((standalone_debug))` that can be used on classes to
ignore ctor homing.
Bug: https://bugs.llvm.org/show_bug.cgi?id=46537
Differential Revision: https://reviews.llvm.org/D106084
Summary:
-debug-info-kind=constructor reduces the amount of class debug info that
is emitted; this patch switches to using this as the default.
Constructor homing emits the complete type info for a class only when the
constructor is emitted, so it is expected that there will be some classes that
are not defined in the debug info anymore because they are never constructed,
and we shouldn't need debug info for these classes.
I compared the PDB files for clang, and there are 273 class types that are defined with `=limited`
but not with `=constructor` (out of ~60,000 total class types).
We've looked at a number of the types that are no longer defined with =constructor. The vast
majority of cases are something like class A is used as a parameter in a member function of
some other class B, which is emitted. But the function that uses class A is never called, and class A
is never constructed, and therefore isn't emitted in the debug info.
Bug: https://bugs.llvm.org/show_bug.cgi?id=46537
Subscribers: aprantl, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D79147
Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify a symbol with an address that
can be relocated against.
Rather than attempt to resolve the variable's value within the IR execution, the
values of all constants can be looked up and incorporated into the AST of the
record type as a literal, mirroring the original compiler AST.
This change applies to DIA and native PDB loaders.
Patch By: jackoalan
Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor
Reviewed By: aleksandr.urakov
Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D82160
This reverts commit 525a591f0f48b9d54018bf5245f2abee09c9c1c8.
Fixed an issue with pointers to members based on typedefs. In this case,
LLVM would emit a second UDT. I fixed it by not passing the class type
to getTypeIndex when the base type is not a function type. lowerType
only uses the class type for direct function types. This suggests if we
have a PMF with a function typedef, there may be an issue, but that can
be solved separately.
> Before this patch, S_[L|G][THREAD32|DATA32] records were emitted with a simple name, not the fully qualified name (namespace + class scope).
>
> Differential Revision: https://reviews.llvm.org/D79447
This causes asserts in Chromium builds:
CodeViewDebug.cpp:2997: void llvm::CodeViewDebug::emitDebugInfoForUDTs(const std::vector<std::pair<std::string, const DIType *>> &):
Assertion `OriginalSize == UDTs.size()' failed.
I will follow up on the Phabricator issue.
Before this patch, S_[L|G][THREAD32|DATA32] records were emitted with a simple name, not the fully qualified name (namespace + class scope).
Differential Revision: https://reviews.llvm.org/D79447
