[lldb-dev] Making changes to the SB API
Leonard Mosescu via lldb-dev
lldb-dev at lists.llvm.org
Mon Jun 11 12:20:49 PDT 2018
Thanks. I wasn't sure how well C++ overloading works with SWIG, that's
definitely a more ergonomic solution.
On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton <clayborg at gmail.com> wrote:
> 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
> 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.
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev