[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