[lldb-dev] Making changes to the SB API
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Fri Jun 8 13:16:42 PDT 2018
> On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> What is the governing philosophy around making changes to the SB API? The "SB API Coding Rules <http://lldb.llvm.org/SB-api-coding-rules.html>"
> page establishes the practices on how to avoid introducing accidental incompatibility, but what
> about the cases where there's a case for intentionally making changes?
>
> For example, I'd like to make a small change to SBTarget to allow surfacing errors during LoadCore():
>
> SBProcess SBTarget::LoadCore(const char *core_file)
>
> And add an explicit out error parameter (in line with SBTarget::Attach(), Launch(), ...):
>
> SBProcess SBTarget::LoadCore(const char *core_file, SBError &error)
>
> If the rule is to strictly avoid any kind of changes then I'd have to resort to
> a COM-like versioning and introduce a new SBTarget::LoadCore2 (or LoadCoreEx, ... pick
> your poison, I'm not set on any name) while also keeping the existing LoadCore().
>
> Any guidance on this? Thanks!
>
Just add an extra overloaded version of LoadCore. We don't want people's code to not link and since Apple uses a LLDBRPC.framework that sub-launches a lldb-rpc-server which can connect to older LLDB.framework binaries, we can't remove functions.
Greg
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180608/72a792dc/attachment-0001.html>
More information about the lldb-dev
mailing list