<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp, branch users/nico/python-2</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] Add filter option to AST dump command (#142164)</title>
<updated>2025-06-02T09:55:04+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-06-02T09:55:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0f7e10b0272bb297568075e73cf76abbf10db4f8'/>
<id>0f7e10b0272bb297568075e73cf76abbf10db4f8</id>
<content type='text'>
Depends on https://github.com/llvm/llvm-project/pull/142163

This patch makes the `-ast-dump-filter` Clang option available to the
`target modules dump ast` command. This allows us to selectively dump
parts of the AST by name.

The AST can quickly grow way too large to skim on the console. This will
aid in debugging AST related issues.

Example:
```
(lldb) target modules dump ast --filter func
Dumping clang ast for 48 modules.
Dumping func:
FunctionDecl 0xc4b785008 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; func 'void (int)' extern
|-ParmVarDecl 0xc4b7853d8 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; x 'int'
`-AsmLabelAttr 0xc4b785358 &lt;&lt;invalid sloc&gt;&gt; Implicit "_Z4funcIiEvT_"

Dumping func&lt;int&gt;:
FunctionDecl 0xc4b7850b8 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; func&lt;int&gt; 'void (int)' implicit_instantiation extern
|-TemplateArgument type 'int'
| `-BuiltinType 0xc4b85b110 'int'
`-ParmVarDecl 0xc4b7853d8 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; x 'int'
```

The majority of this patch is adjust the `Dump` API. The main change in
behaviour is in `TypeSystemClang::Dump`, where we now use the
`ASTPrinter` for dumping the `TranslationUnitDecl`. This is where the
`-ast-dump-filter` functionality lives in Clang.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Depends on https://github.com/llvm/llvm-project/pull/142163

This patch makes the `-ast-dump-filter` Clang option available to the
`target modules dump ast` command. This allows us to selectively dump
parts of the AST by name.

The AST can quickly grow way too large to skim on the console. This will
aid in debugging AST related issues.

Example:
```
(lldb) target modules dump ast --filter func
Dumping clang ast for 48 modules.
Dumping func:
FunctionDecl 0xc4b785008 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; func 'void (int)' extern
|-ParmVarDecl 0xc4b7853d8 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; x 'int'
`-AsmLabelAttr 0xc4b785358 &lt;&lt;invalid sloc&gt;&gt; Implicit "_Z4funcIiEvT_"

Dumping func&lt;int&gt;:
FunctionDecl 0xc4b7850b8 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; func&lt;int&gt; 'void (int)' implicit_instantiation extern
|-TemplateArgument type 'int'
| `-BuiltinType 0xc4b85b110 'int'
`-ParmVarDecl 0xc4b7853d8 &lt;&lt;invalid sloc&gt;&gt; &lt;invalid sloc&gt; x 'int'
```

The majority of this patch is adjust the `Dump` API. The main change in
behaviour is in `TypeSystemClang::Dump`, where we now use the
`ASTPrinter` for dumping the `TranslationUnitDecl`. This is where the
`-ast-dump-filter` functionality lives in Clang.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add templated CompilerType::GetTypeSystem (NFC) (#140424)</title>
<updated>2025-05-21T19:03:58+00:00</updated>
<author>
<name>Dave Lee</name>
<email>davelee.com@gmail.com</email>
</author>
<published>2025-05-21T19:03:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e424787a95f2b88ff6f724fd92d87dd0f1cecddc'/>
<id>e424787a95f2b88ff6f724fd92d87dd0f1cecddc</id>
<content type='text'>
Add an overloaded `GetTypeSystem` to specify the expected type system subclass. Changes code from  `GetTypeSystem().dyn_cast_or_null&lt;TypeSystemClang&gt;()` to `GetTypeSystem&lt;TypeSystemClang&gt;()`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add an overloaded `GetTypeSystem` to specify the expected type system subclass. Changes code from  `GetTypeSystem().dyn_cast_or_null&lt;TypeSystemClang&gt;()` to `GetTypeSystem&lt;TypeSystemClang&gt;()`.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Upgrade CompilerType::GetBitSize to return llvm::Expected  (#129601)</title>
<updated>2025-03-05T18:21:19+00:00</updated>
<author>
<name>Adrian Prantl</name>
<email>aprantl@apple.com</email>
</author>
<published>2025-03-05T18:21:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=878a64f94a264ea4b564d6063614ddb0b5da3f6c'/>
<id>878a64f94a264ea4b564d6063614ddb0b5da3f6c</id>
<content type='text'>
This patch pushes the error handling boundary for the GetBitSize()
methods from Runtime into the Type and CompilerType APIs. This makes it
easier to diagnose problems thanks to more meaningful error messages
being available. GetBitSize() is often the first thing LLDB asks about a
type, so this method is particularly important for a better user
experience.

rdar://145667239</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch pushes the error handling boundary for the GetBitSize()
methods from Runtime into the Type and CompilerType APIs. This makes it
easier to diagnose problems thanks to more meaningful error messages
being available. GetBitSize() is often the first thing LLDB asks about a
type, so this method is particularly important for a better user
experience.

rdar://145667239</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Renaissance LineTable sequences (#127800)</title>
<updated>2025-02-20T11:17:11+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-02-20T11:17:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=367ecc63338da1ff98d63a41bafc9b54d5c3eb6d'/>
<id>367ecc63338da1ff98d63a41bafc9b54d5c3eb6d</id>
<content type='text'>
LineSeqeunce is basically a vector, except that users aren't supposed to
know that. This implements the same concept in a slightly simpler
fashion.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
LineSeqeunce is basically a vector, except that users aren't supposed to
know that. This implements the same concept in a slightly simpler
fashion.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use the first address range as the function address (#122440)</title>
<updated>2025-01-24T11:50:06+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-01-24T11:50:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=57b48987f6c21e369e7bb1626dc79ca74aa34fdb'/>
<id>57b48987f6c21e369e7bb1626dc79ca74aa34fdb</id>
<content type='text'>
This is the behavior expected by DWARF. It also requires some fixups to
algorithms which were storing the addresses of some objects (Blocks and
Variables) relative to the beginning of the function.

There are plenty of things that still don't work in this setups, but
this change is sufficient for the expression evaluator to correctly
recognize the entry point of a function in this case.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the behavior expected by DWARF. It also requires some fixups to
algorithms which were storing the addresses of some objects (Blocks and
Variables) relative to the beginning of the function.

There are plenty of things that still don't work in this setups, but
this change is sufficient for the expression evaluator to correctly
recognize the entry point of a function in this case.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add Function::GetAddress and redirect some uses (#115836)</title>
<updated>2025-01-10T08:56:55+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-01-10T08:56:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=66a88f62cd56e55b5fa0ddb1bdffa549f7565f8f'/>
<id>66a88f62cd56e55b5fa0ddb1bdffa549f7565f8f</id>
<content type='text'>
Many calls to Function::GetAddressRange() were not interested in the
range itself. Instead they wanted to find the address of the function
(its entry point) or the base address for relocation of function-scoped
entities (technically, the two don't need to be the same, but there's
isn't good reason for them not to be). This PR creates a separate
function for retrieving this, and changes the existing
(non-controversial) uses to call that instead.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Many calls to Function::GetAddressRange() were not interested in the
range itself. Instead they wanted to find the address of the function
(its entry point) or the base address for relocation of function-scoped
entities (technically, the two don't need to be the same, but there's
isn't good reason for them not to be). This PR creates a separate
function for retrieving this, and changes the existing
(non-controversial) uses to call that instead.</pre>
</div>
</content>
</entry>
<entry>
<title>Reapply "[lldb] Use the function block as a source for function ranges (#117996)"</title>
<updated>2024-12-03T10:58:36+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2024-12-03T09:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=51b74bb9f6457cbe53776a2a35296189c5db52f3'/>
<id>51b74bb9f6457cbe53776a2a35296189c5db52f3</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[lldb] Use the function block as a source for function ranges (#117996)"</title>
<updated>2024-12-03T09:27:31+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2024-12-03T09:27:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2526d5b1689389da9b194b5ec2878cfb2f4aca93'/>
<id>2526d5b1689389da9b194b5ec2878cfb2f4aca93</id>
<content type='text'>
This reverts commit ba14dac481564000339ba22ab867617590184f4c. I guess
"has no conflicts" doesn't mean "it will build".
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit ba14dac481564000339ba22ab867617590184f4c. I guess
"has no conflicts" doesn't mean "it will build".
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use the function block as a source for function ranges (#117996)</title>
<updated>2024-12-03T09:21:04+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2024-12-03T09:21:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ba14dac481564000339ba22ab867617590184f4c'/>
<id>ba14dac481564000339ba22ab867617590184f4c</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Make sure Blocks always have a parent (#117683)</title>
<updated>2024-11-27T08:51:59+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2024-11-27T08:51:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e8a01e75e6b17e84710e7cc3bfb70d95a3a696a2'/>
<id>e8a01e75e6b17e84710e7cc3bfb70d95a3a696a2</id>
<content type='text'>
It's basically true already (except for a brief time during
construction). This patch makes sure the objects are constructed with a
valid parent and enforces this in the type system, which allows us to
get rid of some nullptr checks.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It's basically true already (except for a brief time during
construction). This patch makes sure the objects are constructed with a
valid parent and enforces this in the type system, which allows us to
get rid of some nullptr checks.</pre>
</div>
</content>
</entry>
</feed>
