There are two APS sets already in lldb. There is the SB API's which are in the include/API directory. Those are a C++ API that has been crafted to be binary stable (classes with no virtual methods and a fixed set of ivars. That should serve for folks that want a stable API to use lldb as a client (e.g. to use it to write Xcode.)
But there are some tasks in lldb (e.g. implementing a new Process plugin, or Disassembler plugin or whatever)) that is is not possible to do at present using the SB API's. For those you have to use the lldb_private API's. For now these tasks are considered part of the lldb project itself, and the fact that there is a plugin architecture to manage these is more an architectural division than a strategy for "third party" extensions. If we get a strong demand to write this sort of plugin that can be maintained externally to the lldb-dev community, then we'll have to come up with a way to do so through the SB API's. What sort of thing are you trying to do? Jim On Sep 26, 2013, at 10:48 AM, Joe Ranieri <[email protected]> wrote: > On Thu, Sep 26, 2013 at 1:05 PM, Greg Clayton <[email protected]> wrote: >> Currently they have to be built in because the internals of lldb (anything >> inside the "lldb_private" namespace) can change at anytime. >> >> In order to allow external plug-ins, we would need to make sure to make sure >> the API doesn't get violated. There are some important rules in place right >> now since we are vending a C++ API: >> 1 - No virtual functions in any public classes (lldb::SB*) >> 2 - No inheritance >> 3 - One member which is an opaque pointer that never changes size (shared >> pointer, weak pointer, auto_ptr/unique_ptr, or just a pointer if the object >> never gets destroyed). >> >> This allows people to link against the C++ classes and maintains a stable >> C++ API. >> >> The problem with making plug-ins that only use the public interface, is it >> is challenging to abide by these rules. I am sure we can do it, we just >> haven't done it yet. For some plug-ins like disassemblers, it would be >> easier than others, like subclassing a new process plug-in or a new symbol >> file parser since these are create many lldb_private classes. >> >> Greg > > Given the lack of a stable C++ API across shared library boundaries on > some platforms, would it make sense to expose a C API? It seems like > the external plugin's main function could register a struct of > function pointers for each internal plugin type (disassembler, > platform, etc). Internally there'd be subclasses of the lldb_private > classes for the corresponding plugin type that call through to the > appropriate function pointer registered by the external plugin. I > think this is more or less what the OperatingSystemPython class > already does. > > The catch is figuring out how stable the C API would be and how much > it would impede the ability to move the rest of the codebase forward. > > -- Joe Ranieri > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
