[lldb-dev] Development of a Plugin to be loaded in LLDB from external library

[Greg Clayton via lldb-dev]

> On Apr 26, 2016, at 1:50 AM, Abhishek Aggarwal via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hi everyone
> 
> There has been previous discussions in this mailing list regarding Enabling Intel(R) Processor Trace collection in LLDB. A new APIs are being developed to be added to SB APIs that will provide raw traces (collected on lldb-server side). These APIs are Trace technology independent and hence can work for other Tracing technologies also. The decoding of the raw traces can be done outside LLDB. For details you can refer to the thread with the subject "Review of API and remote packets" started on March 31, 2016.
> 
> I am working on developing a Plugin that will use these new APIs to enable Intel(R) Processor Trace technology and collect raw trace data for the inferior being debugged by LLDB. The plugin will perform decoding on the trace data to present it as a meaningful information to the user of LLDB Debugger. I want to use this plugin through LLDB CLI. I have few questions regarding development of this plugin: 
> 
> 1. What is the best way to develop this plugin? Should it be done as shown in "examples/plugins/commands/fooplugin.cpp" ( i.e. a C++ based solution and using 'plugin load <path_of_shared_lib>' command) or should I go for Python based solution to add new commands using Python functions?

I personally would add a new folder for all trace plug-ins:

$(trunk)/source/Plugins/Trace

Then add one for the Intel trace:

$(trunk)/source/Plugins/Trace/Intel

We should then add a new "trace" multi-word command into that would get added into our commands in CommandInterpreter::LoadCommandDictionary():

    m_command_dict["trace"] = CommandObjectSP (new CommandObjectMultiwordTrace (*this));

This command would then have sub commands like "start", "stop", and any other commands we would need in order to display trace data.

> 2. I am planning to upstream this developed plugin in LLDB public repository once the development is finished. Any user that wants to use Intel(R) Processor Trace will be able to do so by compiling this plugin and loading it via LLDB CLI as an external library. What should be the ideal location to place this plugin in LLDB repository? I could think of the 'tools' folder.

All plug-ins right now are all internal to LLDB and are currently developed in the "$(trunk)/source/Plugins" and compiled into LLDB right now. We don't currently have a model where plug-ins can be externally loaded into LLDB as most of the plug-ins use the lldb_private APIs. This is mostly due to C++ and the fragility of exporting classes that could be inherited from. Our public API (anything in the "lldb" namespace is designed to be exported from the LLDB shared library) follows some rules:
1 - No inheritance
2 - No virtual functions
3 - Fixed instance variables that never change (usually a single shared_ptr, unique_ptr or just plain pointer)

This isn't to say we can't start to develop a way to do external plug-ins, but if we do, this will be new work and will involve a lot of thought to ensure that plug-ins will be able to be loaded by current and future versions of LLDB.

The Intel trace plug-in is going to require very close integration with the ProcessGDBRemote if the pluig-in design stays on the course of adding packets to a GDB server so I don't see how you would make a plug-in that can live on the public API and be external. If you go the route of using expressions in order to enable the gathering and do everything by just using what is available in the public API, this can work as a plug-in, but it then loses the ability to add functions to the public LLDB API like we spoke about ( lldb::SBTrace lldb::SBProcess::StartTrace(lldb::SBTraceOptions &options) ).

Greg Clayton