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 On Sep 25, 2013, at 8:58 PM, Félix Cloutier <[email protected]> wrote: > Hello lldb, > > Turns out I'm writing a lot of lldb plugins to get my things working, and > it's becoming rather unhygienic to keep all that stuff in the main project, > especially since most of my work is not relevant to lldb itself. I was > wondering if there was a way I could put those in a dylib instead and load it > like you load any other plugin. > > The LLDB framework doesn't seem to expose the base classes for ABIs, > disassemblers and symbol files, though. > > Is it possible to write those as dynamic library plugins, or do they > absolutely have to be built into the lldb executable? > > Félix > _______________________________________________ > 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
