LLDB plugin dylib

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

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

Er, that should read ABI and not API.

-- Joe Ranieri

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

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