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, [email protected] 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 <[email protected]> wrote: > >> 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 > > _______________________________________________ > 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
