[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