Hi Mike,
Check out this thread from last year:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-August/005049.html
The long and short is that this is actually a dead codepath. Enrico (CC’ed on this thread now) was the original author and had some original plans for it, but it ended up not finding usage and now as far as anyone knows it’s totally unused.
Don’t let that discourage you though. It looks like the infrastructure is there, it just needs some love to get it into a state that it meets your needs.
As for the API stuff, I don’t see a way around building all of LLDB to get this. That public API is going to need to call into the private API somehow, and it does that by statically linking against it. So you will need to build all of LLDB. Can you elaborate on how you envisioned using the API? It might be that there is some subset of the API that you’re interested in that doesn’t need to depend on all the rest of LLDB. Knowing what that subset is would be a good starting point for further discussion though.
Thanks for your response. I found the lldb-3.5.-dev package which contains all the public API headers and libraries necessary to build my plugin independent of a full lldb build. I really hope that loadable lldb plugins do not go away in the future.
My plugin (sosplugin) is fairly simple. It registers the “sos” command and when the command is executed the “libsos.so” library is loaded and second argument on the command line is used to find a symbol/entry point in the sos library that matches. The “libsos.so” is some of the Windows/Windbg sos debugger extension ported to Linux. When the command entry point is called in libsos.so the rest of the command line and a simple interface is passed that implements some of the services the extension needs from the hosting debugger.
My “soscommand1” branch in the https://github.com/mikem8361/coreclr.git repository contains the current versions of these modules under src/ToolBox/SOS/lldbplugin and src/ToolBox/SOS/strike.
mikem
I doubt they would go away if there’s an actual user of them, and if they did go away and someone who needed them came along, I expect they would be able to put them back, provided they were committed to maintaining it and turning it into something that was generally useful outside the context of a narrowly defined set of needs.
So my suggestion would be to try to make the loadable plugin system work for you and extending / improving it wherever you run into limitations.
Feel free to hack around and propose patches to this effect.
And for what it’s worth, I also have some interest in seeing the loadable plugin system developed further as i have some ideas of how I would like to use it in the future, although this is still a ways out for me.
Thanks for your response. I found the lldb-3.5.-dev package which contains all the public API headers and libraries necessary to build my plugin independent of a full lldb build. I really hope that loadable lldb plugins do not go away in the future.
My plugin (sosplugin) is fairly simple. It registers the “sos” command and when the command is executed the “libsos.so” library is loaded and second argument on the command line is used to find a symbol/entry point in the sos library that matches. The “libsos.so” is some of the Windows/Windbg sos debugger extension ported to Linux. When the command entry point is called in libsos.so the rest of the command line and a simple interface is passed that implements some of the services the extension needs from the hosting debugger.
My “soscommand1” branch in the https://github.com/mikem8361/coreclr.git repository contains the current versions of these modules under src/ToolBox/SOS/lldbplugin and src/ToolBox/SOS/strike.
mikem