<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp, 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][NativePDB] Estimate symbol sizes (#165727)</title>
<updated>2025-10-31T09:33:37+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-31T09:33:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=44fefe70e41a3b8e68545f45798740f74f4231cd'/>
<id>44fefe70e41a3b8e68545f45798740f74f4231cd</id>
<content type='text'>
In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).

This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).

This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.</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][NativePDB] Consolidate simple types (#163209)</title>
<updated>2025-10-15T11:42:14+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-15T11:42:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4b89704504dde687ba7983e034cb246581fd1407'/>
<id>4b89704504dde687ba7983e034cb246581fd1407</id>
<content type='text'>
This aligns the simple types created by the native plugin with the ones
from DIA as well as LLVM and the original cvdump.

- A few type names weren't handled when creating the LLDB `Type` name
(e.g. `short`)
- 64-bit integers were created as `(u)int64_t` and are now created as
`(unsigned) long long` (matches DIA)
- 128-bit integers (only supported by clang-cl) weren't created as types
(they have `SimpleTypeKind::(U)Int128Oct`)
- All complex types had the same name - now they have `_Complex
&lt;float-type&gt;`

Some types like `SimpleTypeKind::Float48` can't be tested because they
can't be created in C++.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This aligns the simple types created by the native plugin with the ones
from DIA as well as LLVM and the original cvdump.

- A few type names weren't handled when creating the LLDB `Type` name
(e.g. `short`)
- 64-bit integers were created as `(u)int64_t` and are now created as
`(unsigned) long long` (matches DIA)
- 128-bit integers (only supported by clang-cl) weren't created as types
(they have `SimpleTypeKind::(U)Int128Oct`)
- All complex types had the same name - now they have `_Complex
&lt;float-type&gt;`

Some types like `SimpleTypeKind::Float48` can't be tested because they
can't be created in C++.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Use typedef compiler type for typedef types (#156250)</title>
<updated>2025-10-13T09:49:39+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-13T09:49:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=648b3aab478840cd72913d23cbbb425dc890f86a'/>
<id>648b3aab478840cd72913d23cbbb425dc890f86a</id>
<content type='text'>
Before this PR, the native PDB plugin would create the following LLDB
`Type` for `using SomeTypedef = long`:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x000002becd8d8620 long
```
with this PR, the following is created:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x0000024d6a7e3c90 typedef SomeTypedef
```

This matches the behavior of the DIA PDB plugin and works towards making
[`Shell/SymbolFile/PDB/typedefs.test`](https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/SymbolFile/PDB/typedefs.test)
pass with the native plugin.

I added a similar test to the `NativePDB` shell tests to capture the
current state, which doesn't quite match that of DIA yet. I'll add some
comments on what's missing on this PR, because I'm not fully sure what
the correct output would be.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this PR, the native PDB plugin would create the following LLDB
`Type` for `using SomeTypedef = long`:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x000002becd8d8620 long
```
with this PR, the following is created:
```
Type{0x00002e03} , name = "SomeTypedef", size = 4, compiler_type = 0x0000024d6a7e3c90 typedef SomeTypedef
```

This matches the behavior of the DIA PDB plugin and works towards making
[`Shell/SymbolFile/PDB/typedefs.test`](https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/SymbolFile/PDB/typedefs.test)
pass with the native plugin.

I added a similar test to the `NativePDB` shell tests to capture the
current state, which doesn't quite match that of DIA yet. I'll add some
comments on what's missing on this PR, because I'm not fully sure what
the correct output would be.</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][NativePDB] Add modifiers to modified type name (#159296)</title>
<updated>2025-09-18T09:55:15+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-18T09:55:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4625c8f076a85a4b3799a71b9299424a426a9de3'/>
<id>4625c8f076a85a4b3799a71b9299424a426a9de3</id>
<content type='text'>
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&amp; __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](https://github.com/llvm/llvm-project/blob/b29c7ded31d81ca47aed0157c543c8b6a0f5866c/lldb/test/Shell/SymbolFile/PDB/func-symbols.test)
also relies on this.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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&amp; __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](https://github.com/llvm/llvm-project/blob/b29c7ded31d81ca47aed0157c543c8b6a0f5866c/lldb/test/Shell/SymbolFile/PDB/func-symbols.test)
also relies on this.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][TypeSystem] Enable colored AST dump (#86159)</title>
<updated>2025-09-15T17:03:55+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-09-15T17:03:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=95d5d984db4092136ad4b178b765516168c31b9e'/>
<id>95d5d984db4092136ad4b178b765516168c31b9e</id>
<content type='text'>
This patch causes the various AST dump commands (`target modules dump
ast`/`target dump typesystem`) to be color-highlighted. I added a `bool
show_color` parameter to `SymbolFile::DumpClangAST` and
`TypeSystem::Dump`. In `TypeSystemClang` I temporarily sets the
`getShowColors` flag on the owned Clang AST (using an RAII helper) for
the duration of the AST dump. We use `Debugger::GetUseColors` to decide
whether to color the AST dump.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch causes the various AST dump commands (`target modules dump
ast`/`target dump typesystem`) to be color-highlighted. I added a `bool
show_color` parameter to `SymbolFile::DumpClangAST` and
`TypeSystem::Dump`. In `TypeSystemClang` I temporarily sets the
`getShowColors` flag on the owned Clang AST (using an RAII helper) for
the duration of the AST dump. We use `Debugger::GetUseColors` to decide
whether to color the AST dump.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Implement `AddSymbols` (#154121)</title>
<updated>2025-09-11T20:35:19+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-11T20:35:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=65787728b72a2b1f1bfdefd15d32ec0a69f2b941'/>
<id>65787728b72a2b1f1bfdefd15d32ec0a69f2b941</id>
<content type='text'>
This PR implements `SymbolFileNativePDB::AddSymbols` which adds public
symbols to the symbol table.

These symbols are found in the publics stream. It contains mangled names
coupled with addresses. Addresses are a pair of (segment, offset).
If I understood correctly, then the segment is the section ID from the
COFF header. Sections are already
[constructed](https://github.com/llvm/llvm-project/blob/c48ec7fb60b5e0b4100731d75f82ea63c0ec7b45/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp#L1048)
using this 1-based index ([MS
docs](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers)).
This allows us to use `section_list-&gt;FindSectionByID`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR implements `SymbolFileNativePDB::AddSymbols` which adds public
symbols to the symbol table.

These symbols are found in the publics stream. It contains mangled names
coupled with addresses. Addresses are a pair of (segment, offset).
If I understood correctly, then the segment is the section ID from the
COFF header. Sections are already
[constructed](https://github.com/llvm/llvm-project/blob/c48ec7fb60b5e0b4100731d75f82ea63c0ec7b45/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp#L1048)
using this 1-based index ([MS
docs](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers)).
This allows us to use `section_list-&gt;FindSectionByID`.</pre>
</div>
</content>
</entry>
</feed>
