<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/SystemRuntime, 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>Reapply "[lldb/cmake] Plugin layering enforcement mechanism (#144543)" (#145305)</title>
<updated>2025-06-24T09:10:35+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-06-24T09:10:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=46e1e9f104c853a49316b86ff0c6ca4380735a09'/>
<id>46e1e9f104c853a49316b86ff0c6ca4380735a09</id>
<content type='text'>
The only difference from the original PR are the added BRIEF and
FULL_DOCS arguments to define_property, which are required for
cmake&lt;3.23.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The only difference from the original PR are the added BRIEF and
FULL_DOCS arguments to define_property, which are required for
cmake&lt;3.23.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[lldb/cmake] Plugin layering enforcement mechanism (#144543)"</title>
<updated>2025-06-23T10:07:10+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-06-23T10:05:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=18f667d804144e74d3ba2c67ee6f3610916002a8'/>
<id>18f667d804144e74d3ba2c67ee6f3610916002a8</id>
<content type='text'>
Causes failures on several bots.

This reverts commits 714b2fdf3a385e5b9a95c435f56b1696ec3ec9e8 and
e7c1da7c8ef31c258619c1668062985e7ae83b70.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Causes failures on several bots.

This reverts commits 714b2fdf3a385e5b9a95c435f56b1696ec3ec9e8 and
e7c1da7c8ef31c258619c1668062985e7ae83b70.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb/cmake] Plugin layering enforcement mechanism (#144543)</title>
<updated>2025-06-23T09:31:26+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-06-23T09:31:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e7c1da7c8ef31c258619c1668062985e7ae83b70'/>
<id>e7c1da7c8ef31c258619c1668062985e7ae83b70</id>
<content type='text'>
Some inter-plugin dependencies are okay, others are not. Yet others not,
but we're sort of stuck with them. The idea is to be able to prevent
backsliding while making sure that acceptable dependencies are..
accepted. For context, see
https://github.com/llvm/llvm-project/pull/139170 and the attached
changes to the documentation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some inter-plugin dependencies are okay, others are not. Yet others not,
but we're sort of stuck with them. The idea is to be able to prevent
backsliding while making sure that acceptable dependencies are..
accepted. For context, see
https://github.com/llvm/llvm-project/pull/139170 and the attached
changes to the documentation.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] [darwin] Upstream a few DriverKit cases (#126604)</title>
<updated>2025-02-10T22:49:53+00:00</updated>
<author>
<name>Jason Molenda</name>
<email>jmolenda@apple.com</email>
</author>
<published>2025-02-10T22:49:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d90399603c1db201be830a895f3b1324c4b30d07'/>
<id>d90399603c1db201be830a895f3b1324c4b30d07</id>
<content type='text'>
A DriverKit process is a kernel extension that runs in userland, instead
of running in the kernel address space/priv levels, they've been around
a couple of years. From lldb's perspective a DriverKit process is no
different from any other userland level process, but it has a different
Triple so we need to handle those cases in the lldb codebase. Some of
the DriverKit triple handling had been upstreamed to llvm-project, but I
noticed a few cases that had not yet. Cleaning that up.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A DriverKit process is a kernel extension that runs in userland, instead
of running in the kernel address space/priv levels, they've been around
a couple of years. From lldb's perspective a DriverKit process is no
different from any other userland level process, but it has a different
Triple so we need to handle those cases in the lldb codebase. Some of
the DriverKit triple handling had been upstreamed to llvm-project, but I
noticed a few cases that had not yet. Cleaning that up.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add SymbolContext::GetFunctionOrSymbolAddress (#123340)</title>
<updated>2025-02-06T08:12:44+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-02-06T08:12:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=feb5a77d700f46d6638f073d411cbe0d8a924fdf'/>
<id>feb5a77d700f46d6638f073d411cbe0d8a924fdf</id>
<content type='text'>
Many uses of SC::GetAddressRange were not interested in the range, but
in the address of the function/symbol contained inside the symbol
context. They were getting that by calling the GetBaseAddress on the
returned range, which worked well enough so far, but isn't compatible
with discontinuous functions, whose address (entry point) may not be the
lowest address in the range.

To resolve this problem, this PR creates a new function whose purpose is
return the address of the function or symbol inside the symbol context.
It also changes all of the callers of GetAddressRange which do not
actually care about the range to call this function instead.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Many uses of SC::GetAddressRange were not interested in the range, but
in the address of the function/symbol contained inside the symbol
context. They were getting that by calling the GetBaseAddress on the
returned range, which worked well enough so far, but isn't compatible
with discontinuous functions, whose address (entry point) may not be the
lowest address in the range.

To resolve this problem, this PR creates a new function whose purpose is
return the address of the function or symbol inside the symbol context.
It also changes all of the callers of GetAddressRange which do not
actually care about the range to call this function instead.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Move ValueObject into its own library (NFC) (#113393)</title>
<updated>2024-10-25T03:20:48+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-10-25T03:20:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b852fb1ec5fa15f0b913cc4988cbd09239b19904'/>
<id>b852fb1ec5fa15f0b913cc4988cbd09239b19904</id>
<content type='text'>
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Turn lldb_private::Status into a value type. (#106163)</title>
<updated>2024-08-27T17:59:31+00:00</updated>
<author>
<name>Adrian Prantl</name>
<email>aprantl@apple.com</email>
</author>
<published>2024-08-27T17:59:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0642cd768b80665585c8500bed2933a3b99123dc'/>
<id>0642cd768b80665585c8500bed2933a3b99123dc</id>
<content type='text'>
This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status&amp; error)
`
to

`    llvm::Expected&lt;ResultTy&gt; DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status&amp; error)
`
to

`    llvm::Expected&lt;ResultTy&gt; DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add frame recognizers for libc++ `std::invoke` (#105695)</title>
<updated>2024-08-27T17:15:42+00:00</updated>
<author>
<name>Adrian Vogelsgesang</name>
<email>avogelsgesang@salesforce.com</email>
</author>
<published>2024-08-27T17:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dd060bdede8edec18ad5ca122e15cc24a821e3fe'/>
<id>dd060bdede8edec18ad5ca122e15cc24a821e3fe</id>
<content type='text'>
With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.

The regular expression passed into `AddRecognizer` became problematic,
as it was evaluated on the demangled name. Those names also included
result types for C++ symbols. For `std::__invoke` the return type is a
huge `decltype(...)`, making the regular expresison really hard to
write.

Instead, I added support to `AddRecognizer` for matching on the
demangled names without result type and argument types.

By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.

Co-authored-by: Adrian Prantl &lt;aprantl@apple.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.

The regular expression passed into `AddRecognizer` became problematic,
as it was evaluated on the demangled name. Those names also included
result types for C++ symbols. For `std::__invoke` the return type is a
huge `decltype(...)`, making the regular expresison really hard to
write.

Instead, I added support to `AddRecognizer` for matching on the
demangled names without result type and argument types.

By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.

Co-authored-by: Adrian Prantl &lt;aprantl@apple.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][AIX] 1. Avoid namespace collision on other platforms (#104679)</title>
<updated>2024-08-20T09:19:32+00:00</updated>
<author>
<name>Dhruv Srivastava</name>
<email>dhruv.srivastava@ibm.com</email>
</author>
<published>2024-08-20T09:19:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b804516dc5cf2bb99ff02aa49f9d4da76d721ea9'/>
<id>b804516dc5cf2bb99ff02aa49f9d4da76d721ea9</id>
<content type='text'>
This PR is in reference to porting LLDB on AIX.

Link to discussions on llvm discourse and github:
1.  https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2.  #101657 

The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601

The changes on this PR are intended to avoid namespace collision for
certain typedefs between lldb and other platforms:
1. tid_t --&gt; lldb::tid_t
2. offset_t --&gt; lldb::offset_t</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR is in reference to porting LLDB on AIX.

Link to discussions on llvm discourse and github:
1.  https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2.  #101657 

The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601

The changes on this PR are intended to avoid namespace collision for
certain typedefs between lldb and other platforms:
1. tid_t --&gt; lldb::tid_t
2. offset_t --&gt; lldb::offset_t</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Fix a warning</title>
<updated>2024-08-02T18:10:21+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-08-02T18:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1fcddc0dfa1b371bc0b278438d5f47cf8d03b511'/>
<id>1fcddc0dfa1b371bc0b278438d5f47cf8d03b511</id>
<content type='text'>
This patch fixes:

  lldb/source/Plugins/SystemRuntime/MacOSX/AbortWithPayloadFrameRecognizer.cpp:177:10:
  error: unused variable 'str_len' [-Werror,-Wunused-variable]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes:

  lldb/source/Plugins/SystemRuntime/MacOSX/AbortWithPayloadFrameRecognizer.cpp:177:10:
  error: unused variable 'str_len' [-Werror,-Wunused-variable]
</pre>
</div>
</content>
</entry>
</feed>
