[Lldb-commits] [PATCH] D120100: [lldb] Expose eBroadcastBitProgress to the SWIG SBAPI

Greg Clayton via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Feb 17 23:01:02 PST 2022


clayborg added a comment.

We have been quite stable on our public API over the years which allows people to create native tools that link against our public API and we don't regress it so things always compile or would actually still run against an older LLDB library.

In D120100#3331209 <https://reviews.llvm.org/D120100#3331209>, @mib wrote:

> In D120100#3331141 <https://reviews.llvm.org/D120100#3331141>, @JDevlieghere wrote:
>
>> Removing the enum from SBDebugger is an ABI breaking change. I think this has been in tree for a while, so if we shipped this like this in the last release, we cannot guarantee that this won't break anyone. Can we avoid the issue by defining the enum in the interface file?
>
> Please, correct me if I'm wrong but in my understanding, this is partially implemented from the ABI standpoint as it's not defined in the SWIG interface file. Even though it's defined in the C++ liblldb, I don't think it reaches a bigger audience than the Python `lldb` module.

lldb-vscode.cpp links against it, so it is being used. For Swift support, we rely on the fact that an binary like lldb-rpc-server or lldb-vscode can target newer LLDB libraries both from a building against headers perspective and also from a newer executable running with an older LLDB library standpoint.

> Defining it in the interface file will increase the maintenance burden so I think it's reasonable to "break" the ABI in this case. Do you see any objection @clayborg ?

So yes, in order to keep our API stable I object.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120100/new/

https://reviews.llvm.org/D120100



More information about the lldb-commits mailing list