<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/test/Shell/SymbolFile/PDB, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[LLDB] Use native PDB reader by default (#165363)</title>
<updated>2025-10-29T15:51:38+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-29T15:51:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=287ca7b243facc7185bbd9dfdaa5a6a012819e1b'/>
<id>287ca7b243facc7185bbd9dfdaa5a6a012819e1b</id>
<content type='text'>
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).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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).</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][PDB] Run `function-nested-block.test` with both plugins (#165364)</title>
<updated>2025-10-28T10:43:47+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-28T10:43:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7bb0d96e87e0129b960bb6a0a89de1a9a38f9f95'/>
<id>7bb0d96e87e0129b960bb6a0a89de1a9a38f9f95</id>
<content type='text'>
This test passes with both plugins, but only ran with the DIA plugin. It
was fixed with #161678, where I missed this test.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This test passes with both plugins, but only ran with the DIA plugin. It
was fixed with #161678, where I missed this test.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Create simple types from function arguments and return types (#163621)</title>
<updated>2025-10-27T13:40:42+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-27T13:40:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=51cecd3f2ec9881b07fb7c2e4c1fb92408f66eb1'/>
<id>51cecd3f2ec9881b07fb7c2e4c1fb92408f66eb1</id>
<content type='text'>
When creating all types in a compilation unit, simple types (~&gt;
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When creating all types in a compilation unit, simple types (~&gt;
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][PDB] Run `pointers.test` with both plugins (#163623)</title>
<updated>2025-10-21T12:04:18+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-21T12:04:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=531d45d767246f910500e84ff981a89b5e0b7b03'/>
<id>531d45d767246f910500e84ff981a89b5e0b7b03</id>
<content type='text'>
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 &lt;code&gt;\`extern "C" main'::\`2'::ST&lt;/code&gt; 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](https://github.com/llvm/llvm-project/blob/2b135b931338a57c38d9c4a34ffdd59877ba82d6/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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;code&gt;\`extern "C" main'::\`2'::ST&lt;/code&gt; 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](https://github.com/llvm/llvm-project/blob/2b135b931338a57c38d9c4a34ffdd59877ba82d6/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.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][PDB] Split `func-symbols.test` between DIA and native (#163733)</title>
<updated>2025-10-21T11:47:39+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-21T11:47:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e9b6d35dc8d9db44bf8f606c778f689f874a8f5c'/>
<id>e9b6d35dc8d9db44bf8f606c778f689f874a8f5c</id>
<content type='text'>
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`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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`.</pre>
</div>
</content>
</entry>
<entry>
<title>Reland "[LLDB][NativePDB] Create functions with mangled name" (#161678)</title>
<updated>2025-10-07T17:27:16+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-07T17:27:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3b14414cbdb8bd37ff861862a99a47104b87765b'/>
<id>3b14414cbdb8bd37ff861862a99a47104b87765b</id>
<content type='text'>
Relands #149701 which was reverted in
https://github.com/llvm/llvm-project/commit/185ae5cdc695248b58ae017508cc764c19bee5b7
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Relands #149701 which was reverted in
https://github.com/llvm/llvm-project/commit/185ae5cdc695248b58ae017508cc764c19bee5b7
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.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[LLDB][NativePDB] Create functions with mangled name (#149701)"</title>
<updated>2025-09-25T20:15:04+00:00</updated>
<author>
<name>Martin Storsjö</name>
<email>martin@martin.st</email>
</author>
<published>2025-09-25T20:13:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=185ae5cdc695248b58ae017508cc764c19bee5b7'/>
<id>185ae5cdc695248b58ae017508cc764c19bee5b7</id>
<content type='text'>
This reverts commit e98f34eb08b2bf7aed787e7f8a7cea9111f044c8.

This broke demangling of Itanium symbols on i386.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit e98f34eb08b2bf7aed787e7f8a7cea9111f044c8.

This broke demangling of Itanium symbols on i386.
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Create functions with mangled name (#149701)</title>
<updated>2025-09-24T14:12:54+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-24T14:12:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e98f34eb08b2bf7aed787e7f8a7cea9111f044c8'/>
<id>e98f34eb08b2bf7aed787e7f8a7cea9111f044c8</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][PDB] Warn if DIA plugin is requested but not available (#160067)</title>
<updated>2025-09-23T10:14:59+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-23T10:14:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5b3dd43bd20d9c4e1cd05e39d2e022b368b0fbdc'/>
<id>5b3dd43bd20d9c4e1cd05e39d2e022b368b0fbdc</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][PDB] Run UDT layout test with native PDB too (#159769)</title>
<updated>2025-09-23T09:34:48+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-23T09:34:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e08d8e3d16d6994df5e42cee7c2672d2fe9cc46c'/>
<id>e08d8e3d16d6994df5e42cee7c2672d2fe9cc46c</id>
<content type='text'>
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`)](https://github.com/llvm/llvm-project/blob/b7e4edca3d56ec87f719c202f5397b245595f7cc/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&lt;0&gt;`, `B&lt;1&gt;`,
`B&lt;2&gt;`, `B&lt;3&gt;`, `A`. The native plugin follows the order of the bases in
memory and prints `B&lt;2&gt;`, `B&lt;3&gt;`, `A`, `B&lt;0&gt;`, `B&lt;1&gt;` (last three are
the virtual bases).
    &lt;details&gt;&lt;summary&gt;Class layout of C&lt;/summary&gt;
    
    ```
    class C size(88):
            +---
    0       | +--- (base class B&lt;2&gt;)
    0       | | {vbptr}
    8       | | _a
    9.      | | _b (bitstart=3,nbits=6)
    11      | | _c
            | +---
    15      | +--- (base class B&lt;3&gt;)
    15      | | {vbptr}
    23      | | _a
    24.     | | _b (bitstart=3,nbits=6)
    26      | | _c
            | +---
            | &lt;alignment member&gt; (size=2)
    32      | _x
    36      | _y
    38      | _z
            | &lt;alignment member&gt; (size=1)
            | &lt;alignment member&gt; (size=2)
            +---
            +--- (virtual base A)
    40      | {vfptr}
    48      | U _u
            | &lt;alignment member&gt; (size=4)
            +---
            +--- (virtual base B&lt;0&gt;)
    56      | {vbptr}
    64      | _a
    65.     | _b (bitstart=3,nbits=6)
    67      | _c
            +---
            +--- (virtual base B&lt;1&gt;)
    71      | {vbptr}
    79      | _a
    80.     | _b (bitstart=3,nbits=6)
    82      | _c
            +---
    ```
    &lt;/details&gt;

I split the tests for the plugins for better readability.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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`)](https://github.com/llvm/llvm-project/blob/b7e4edca3d56ec87f719c202f5397b245595f7cc/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&lt;0&gt;`, `B&lt;1&gt;`,
`B&lt;2&gt;`, `B&lt;3&gt;`, `A`. The native plugin follows the order of the bases in
memory and prints `B&lt;2&gt;`, `B&lt;3&gt;`, `A`, `B&lt;0&gt;`, `B&lt;1&gt;` (last three are
the virtual bases).
    &lt;details&gt;&lt;summary&gt;Class layout of C&lt;/summary&gt;
    
    ```
    class C size(88):
            +---
    0       | +--- (base class B&lt;2&gt;)
    0       | | {vbptr}
    8       | | _a
    9.      | | _b (bitstart=3,nbits=6)
    11      | | _c
            | +---
    15      | +--- (base class B&lt;3&gt;)
    15      | | {vbptr}
    23      | | _a
    24.     | | _b (bitstart=3,nbits=6)
    26      | | _c
            | +---
            | &lt;alignment member&gt; (size=2)
    32      | _x
    36      | _y
    38      | _z
            | &lt;alignment member&gt; (size=1)
            | &lt;alignment member&gt; (size=2)
            +---
            +--- (virtual base A)
    40      | {vfptr}
    48      | U _u
            | &lt;alignment member&gt; (size=4)
            +---
            +--- (virtual base B&lt;0&gt;)
    56      | {vbptr}
    64      | _a
    65.     | _b (bitstart=3,nbits=6)
    67      | _c
            +---
            +--- (virtual base B&lt;1&gt;)
    71      | {vbptr}
    79      | _a
    80.     | _b (bitstart=3,nbits=6)
    82      | _c
            +---
    ```
    &lt;/details&gt;

I split the tests for the plugins for better readability.</pre>
</div>
</content>
</entry>
</feed>
