Just to reiterate a couple of points since I am AFK - thanks for letting us know you're using this. As Zachary said, if we know that people are using it, it's unlikely to go away!
- if you can think of any improvements, definitely suggest them, or even better submit patches I have ideas for the plugins subsystem, and it needs more love than it has had in the past Good luck :-) Sent from my iPhone > On Feb 21, 2015, at 10:49 AM, Mike McLaughlin <mi...@microsoft.com> wrote: > > 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 > > From: Zachary Turner [mailto:ztur...@google.com] > Sent: Friday, February 20, 2015 3:57 PM > To: Mike McLaughlin; lldb-dev@cs.uiuc.edu; Enrico Granata > Subject: Re: [lldb-dev] Building a command plugin for lldb > > 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. > > On Fri Feb 20 2015 at 3:13:12 PM Mike McLaughlin <mi...@microsoft.com> wrote: > I have a couple of questions about lldb: > > 1) I building a lldb command plugin for dotnet/coreclr (sos for lldb) and it > currently depends on the lldb source (API h files) and the lldb build. Is > there a package that includes just the public h and library files necessary > to build a lldb plugin? I’ve heard there is one for llvm. Or am I stuck > enlisting and building lldb to build my plugin? > > 2) Is there any way to get the plugin’s load path? I want to load another > module dynamically in the same directory as my lldb plugin. I’m still > learning about linux and lldb but it doesn’t look like there is a lldb api or > the equivalent of Windows the hmodule passed to the DllMain. > > Thanks. > > mikem > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
