[lldb-dev] LLDB plugin dylib

[Félix Cloutier]

As a hobby, I'm writing a Mac OS 9 emulator/compatibility layer, and I'm implementing a debug stub because my homegrown debugger isn't that great. This means I need a disassembler for PPC code (though I could probably get away with the LLVM disassembler if I tried a bit harder), an ABI plugin, and now a symbol file plugin. I'm pretty much implementing the plugins when I figure out I need them, so I'm not sure how many more plugins I would have to implement to get a "good enough" set of features.

Félix

Le 2013-09-26 à 13:56:19, jingham at apple.com a écrit :

> 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 <joe at alacatialabs.com> wrote:
> 
>> On Thu, Sep 26, 2013 at 1:05 PM, Greg Clayton <gclayton at apple.com> 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
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev