[lldb-dev] LLDB plugin dylib

[Greg Clayton]

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 <felixcca at yahoo.ca> 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
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev