<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/bindings/python, 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] Push down the SWIG module to avoid an import cycle (#166265)</title>
<updated>2025-11-17T18:56:28+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-17T18:56:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=18b5e2a7266bfe8f211be7ae1198e6bed4ab0c06'/>
<id>18b5e2a7266bfe8f211be7ae1198e6bed4ab0c06</id>
<content type='text'>
This is a reland of #129135 (by dingxiangfei2009) with Vladislav
(dzhidzhoev) fix on top.

Fixes #92603</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a reland of #129135 (by dingxiangfei2009) with Vladislav
(dzhidzhoev) fix on top.

Fixes #92603</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Enforce Py_LIMITED_API in the SWIG typemaps (#168147)</title>
<updated>2025-11-15T00:23:06+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-15T00:23:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=94c384c9eeed58d8921e0f5ad6ed1c517c01879f'/>
<id>94c384c9eeed58d8921e0f5ad6ed1c517c01879f</id>
<content type='text'>
We missed a handful of uses of the Python private API in the SWIG
typemaps because they are included before we include the Python header
that defines Py_LIMITED_API.

This fixes that and guards the last private use on whether or not you're
targeting the limited API. Unfortunately there doesn't appear to be an
alternative, so we have to resort to being slightly less defensive.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We missed a handful of uses of the Python private API in the SWIG
typemaps because they are included before we include the Python header
that defines Py_LIMITED_API.

This fixes that and guards the last private use on whether or not you're
targeting the limited API. Unfortunately there doesn't appear to be an
alternative, so we have to resort to being slightly less defensive.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Drop support for the Buffer Protocol (#168144)</title>
<updated>2025-11-15T00:14:26+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-15T00:14:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=21502bddb37ab62e8f51debb3cd20c71e85b6bec'/>
<id>21502bddb37ab62e8f51debb3cd20c71e85b6bec</id>
<content type='text'>
This is an alternative solution to the issue described in #167990, which
can be summarized as that we cannot target Python 3.8 with the stable
API and support building for Python 3.13 and later due to the buffer
protocol.

The approach taken in this PR, and proposed by Ismail, is to sidesteps
the issue by dropping support for the buffer protocol. The only two
users are SBFile::Read and SBFile::Write. Instead, we support PyBytes
and PyByteArray which are the builtin types that conform to the buffer
protocol. Technically, this means a small regression, where those
methods could previously take custom types that conform to Python's
buffer protocol. Like Ismail, I think this is acceptable given the
alternatives.

Co-authored-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is an alternative solution to the issue described in #167990, which
can be summarized as that we cannot target Python 3.8 with the stable
API and support building for Python 3.13 and later due to the buffer
protocol.

The approach taken in this PR, and proposed by Ismail, is to sidesteps
the issue by dropping support for the buffer protocol. The only two
users are SBFile::Read and SBFile::Write. Instead, we support PyBytes
and PyByteArray which are the builtin types that conform to the buffer
protocol. Technically, this means a small regression, where those
methods could previously take custom types that conform to Python's
buffer protocol. Like Ismail, I think this is acceptable given the
alternatives.

Co-authored-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Remove bindings/python/python-typemaps.h (#167966)</title>
<updated>2025-11-13T23:00:07+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-13T23:00:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=36848a3710bf8376f5ec9cb03df684a4b889e343'/>
<id>36848a3710bf8376f5ec9cb03df684a4b889e343</id>
<content type='text'>
The minimum supported SWIG version is 4.0 so there's no need for using a
separate file anymore.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The minimum supported SWIG version is 4.0 so there's no need for using a
separate file anymore.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[lldb] Limit Py_buffer_RAII to SWIG &lt; 4.1" (#167934)</title>
<updated>2025-11-13T19:24:55+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-13T19:24:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1b723f2ddb6826c6532f79804be0cff089bba342'/>
<id>1b723f2ddb6826c6532f79804be0cff089bba342</id>
<content type='text'>
Reverts llvm/llvm-project#167808</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#167808</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Limit Py_buffer_RAII to SWIG &lt; 4.1 (#167808)</title>
<updated>2025-11-13T19:07:21+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-13T19:07:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ac2d3d1da68ddab7f663afec39637452eca35572'/>
<id>ac2d3d1da68ddab7f663afec39637452eca35572</id>
<content type='text'>
The bug [1] this is working around was fixed in SWIG 4.1. The workaround
uses functions and constants that are not part of the limited API, which
I'm trying to eliminate to make LLDB compatible with the Python Limited
C API [2].

[1] https://github.com/swig/swig/issues/1640
[2] https://github.com/llvm/llvm-project/issues/151617</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The bug [1] this is working around was fixed in SWIG 4.1. The workaround
uses functions and constants that are not part of the limited API, which
I'm trying to eliminate to make LLDB compatible with the Python Limited
C API [2].

[1] https://github.com/swig/swig/issues/1640
[2] https://github.com/llvm/llvm-project/issues/151617</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[lldb] Introduce ScriptedFrameProvider for real threads" (#167662)</title>
<updated>2025-11-12T10:13:43+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-11-12T10:13:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b7bc4a2103a77328f50f7e0b08ca073e34673755'/>
<id>b7bc4a2103a77328f50f7e0b08ca073e34673755</id>
<content type='text'>
The new test fails on x86 and arm64 public macOS bots:
```
09:27:59  ======================================================================
09:27:59  FAIL: test_append_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that we can add frames after real stack.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 122, in test_append_frames
09:27:59      self.assertEqual(new_frame_count, original_frame_count + 1)
09:27:59  AssertionError: 5 != 6
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_applies_to_thread (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that applies_to_thread filters which threads get the provider.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 218, in test_applies_to_thread
09:27:59      self.assertEqual(
09:27:59  AssertionError: 5 != 1 : Thread with ID 1 should have 1 synthetic frame
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_prepend_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that we can add frames before real stack.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 84, in test_prepend_frames
09:27:59      self.assertEqual(new_frame_count, original_frame_count + 2)
09:27:59  AssertionError: 5 != 7
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_remove_frame_provider_by_id (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that RemoveScriptedFrameProvider removes a specific provider by ID.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 272, in test_remove_frame_provider_by_id
09:27:59      self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames")
09:27:59  AssertionError: 5 != 3 : Should have 3 synthetic frames
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_replace_all_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that we can replace the entire stack.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 41, in test_replace_all_frames
09:27:59      self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames")
09:27:59  AssertionError: 5 != 3 : Should have 3 synthetic frames
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_scripted_frame_objects (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that provider can return ScriptedFrame objects.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 159, in test_scripted_frame_objects
09:27:59      self.assertEqual(frame0.GetFunctionName(), "custom_scripted_frame_0")
09:27:59  AssertionError: 'thread_func(int)' != 'custom_scripted_frame_0'
09:27:59  - thread_func(int)
09:27:59  + custom_scripted_frame_0
09:27:59  
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ----------------------------------------------------------------------
09:27:59  Ran 6 tests in 14.242s
09:27:59  
09:27:59  FAILED (failures=6)
```

Reverts llvm/llvm-project#161870</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The new test fails on x86 and arm64 public macOS bots:
```
09:27:59  ======================================================================
09:27:59  FAIL: test_append_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that we can add frames after real stack.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 122, in test_append_frames
09:27:59      self.assertEqual(new_frame_count, original_frame_count + 1)
09:27:59  AssertionError: 5 != 6
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_applies_to_thread (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that applies_to_thread filters which threads get the provider.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 218, in test_applies_to_thread
09:27:59      self.assertEqual(
09:27:59  AssertionError: 5 != 1 : Thread with ID 1 should have 1 synthetic frame
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_prepend_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that we can add frames before real stack.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 84, in test_prepend_frames
09:27:59      self.assertEqual(new_frame_count, original_frame_count + 2)
09:27:59  AssertionError: 5 != 7
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_remove_frame_provider_by_id (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that RemoveScriptedFrameProvider removes a specific provider by ID.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 272, in test_remove_frame_provider_by_id
09:27:59      self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames")
09:27:59  AssertionError: 5 != 3 : Should have 3 synthetic frames
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_replace_all_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that we can replace the entire stack.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 41, in test_replace_all_frames
09:27:59      self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames")
09:27:59  AssertionError: 5 != 3 : Should have 3 synthetic frames
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ======================================================================
09:27:59  FAIL: test_scripted_frame_objects (TestScriptedFrameProvider.ScriptedFrameProviderTestCase)
09:27:59     Test that provider can return ScriptedFrame objects.
09:27:59  ----------------------------------------------------------------------
09:27:59  Traceback (most recent call last):
09:27:59    File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 159, in test_scripted_frame_objects
09:27:59      self.assertEqual(frame0.GetFunctionName(), "custom_scripted_frame_0")
09:27:59  AssertionError: 'thread_func(int)' != 'custom_scripted_frame_0'
09:27:59  - thread_func(int)
09:27:59  + custom_scripted_frame_0
09:27:59  
09:27:59  Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang
09:27:59  ----------------------------------------------------------------------
09:27:59  Ran 6 tests in 14.242s
09:27:59  
09:27:59  FAILED (failures=6)
```

Reverts llvm/llvm-project#161870</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Introduce ScriptedFrameProvider for real threads (#161870)</title>
<updated>2025-11-11T20:18:45+00:00</updated>
<author>
<name>Med Ismail Bennani</name>
<email>ismail@bennani.ma</email>
</author>
<published>2025-11-11T20:18:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1e467e44851a9da96c16c0dcd16725f996e6abf7'/>
<id>1e467e44851a9da96c16c0dcd16725f996e6abf7</id>
<content type='text'>
This patch extends ScriptedFrame to work with real (non-scripted)
threads,
enabling frame providers to synthesize frames for native processes.

Previously, ScriptedFrame only worked within
ScriptedProcess/ScriptedThread
contexts. This patch decouples ScriptedFrame from ScriptedThread,
allowing
users to augment or replace stack frames in real debugging sessions for
use
cases like custom calling conventions, reconstructing corrupted frames
from
core files, or adding diagnostic frames.

Key changes:

- ScriptedFrame::Create() now accepts ThreadSP instead of requiring
ScriptedThread, extracting architecture from the target triple rather
than ScriptedProcess.arch

- Added SBTarget::RegisterScriptedFrameProvider() and
ClearScriptedFrameProvider() APIs, with Target storing a
SyntheticFrameProviderDescriptor template for new threads

- Added "target frame-provider register/clear" commands for CLI access

- Thread class gains LoadScriptedFrameProvider(),
ClearScriptedFrameProvider(),
and GetFrameProvider() methods for per-thread frame provider management

- New SyntheticStackFrameList overrides FetchFramesUpTo() to lazily
provide
frames from either the frame provider or the real stack

This enables practical use of the SyntheticFrameProvider infrastructure
in
real debugging workflows.

rdar://161834688

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch extends ScriptedFrame to work with real (non-scripted)
threads,
enabling frame providers to synthesize frames for native processes.

Previously, ScriptedFrame only worked within
ScriptedProcess/ScriptedThread
contexts. This patch decouples ScriptedFrame from ScriptedThread,
allowing
users to augment or replace stack frames in real debugging sessions for
use
cases like custom calling conventions, reconstructing corrupted frames
from
core files, or adding diagnostic frames.

Key changes:

- ScriptedFrame::Create() now accepts ThreadSP instead of requiring
ScriptedThread, extracting architecture from the target triple rather
than ScriptedProcess.arch

- Added SBTarget::RegisterScriptedFrameProvider() and
ClearScriptedFrameProvider() APIs, with Target storing a
SyntheticFrameProviderDescriptor template for new threads

- Added "target frame-provider register/clear" commands for CLI access

- Thread class gains LoadScriptedFrameProvider(),
ClearScriptedFrameProvider(),
and GetFrameProvider() methods for per-thread frame provider management

- New SyntheticStackFrameList overrides FetchFramesUpTo() to lazily
provide
frames from either the frame provider or the real stack

This enables practical use of the SyntheticFrameProvider infrastructure
in
real debugging workflows.

rdar://161834688

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb/Interpreter] Implement ScriptedFrameProvider{,Python}Interface (#166662)</title>
<updated>2025-11-06T19:54:17+00:00</updated>
<author>
<name>Med Ismail Bennani</name>
<email>ismail@bennani.ma</email>
</author>
<published>2025-11-06T19:54:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4cd17eeaeb13f44e7c0783e83716c06a2b9110a3'/>
<id>4cd17eeaeb13f44e7c0783e83716c06a2b9110a3</id>
<content type='text'>
This patch implements the base and python interface for the
ScriptedFrameProvider class.

This is necessary to call python APIs from the ScriptedFrameProvider
that will come in a follow-up.

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch implements the base and python interface for the
ScriptedFrameProvider class.

This is necessary to call python APIs from the ScriptedFrameProvider
that will come in a follow-up.

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;

Signed-off-by: Med Ismail Bennani &lt;ismail@bennani.ma&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Support a Stable ABI LLDB_PYTHON_EXT_SUFFIX (#166269)</title>
<updated>2025-11-05T17:20:10+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-11-05T17:20:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9564b26f81f481f91299ebc446011ed4e5407400'/>
<id>9564b26f81f481f91299ebc446011ed4e5407400</id>
<content type='text'>
When building against the Python Stable API, we should use the `abi3`
ABI tag. Otherwise, Python will refuse to import the native shared
object. This PR adds support for generating a stable ABI compatible
suffix when `LLDB_ENABLE_PYTHON_LIMITED_API` is set.

Previously, on Darwin when building against Python 3.14, you would end
up with `_lldb.cpython-314-darwin.so`. Now, when using the stable ABI,
you get `_lldb.abi3.so` instead. A different version of the Python
interpreter will not consider loading the former, but will load the
latter.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When building against the Python Stable API, we should use the `abi3`
ABI tag. Otherwise, Python will refuse to import the native shared
object. This PR adds support for generating a stable ABI compatible
suffix when `LLDB_ENABLE_PYTHON_LIMITED_API` is set.

Previously, on Darwin when building against Python 3.14, you would end
up with `_lldb.cpython-314-darwin.so`. Now, when using the stable ABI,
you get `_lldb.abi3.so` instead. A different version of the Python
interpreter will not consider loading the former, but will load the
latter.</pre>
</div>
</content>
</entry>
</feed>
