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
