[lldb-dev] OperatingSystem plugin

Alexander Polyakov via lldb-dev lldb-dev at lists.llvm.org
Wed Dec 26 01:37:08 PST 2018

Gentle ping.

On Thu, Dec 20, 2018 at 6:00 PM Alexander Polyakov <polyakov.alx at gmail.com>

> Thank you Jim,
> It's much clearer for me now.
> As you might remember, we discussed an opportunity of adding new OS
> objects to LLDB, e.g. mutexes. The conclusion of our discussion was that if
> we want to do this, we should add such objects to Platform plugin, but is
> there a difference between threads and mutexes for example, both are OS
> specific data structures. Wouldn't it be better to delegate mutexes to
> OperatingSystem plugin? It could deal with them the same way as it deals
> with threads.
> On Thu, Dec 20, 2018 at 1:51 AM Jim Ingham <jingham at apple.com> wrote:
>> You would use an operating system plugin in cases where the underlying
>> process interface doesn't tell the complete story for the OS threads.  For
>> instance, a lot of kernel and bare board OS'es have a gdb-remote stub that
>> just describes the state of the threads currently running on the cores of
>> the machine.  Any swapped out threads are unknown to it.  So the Operating
>> system plugin reconstructs the swapped out threads by looking at OS
>> specific data structures.
>> We didn't think that lldb should own the support for every variant of
>> every OS which might want to reconstruct threads from some data structures
>> in the OS.  After all, this isn't dealing with fairly stable API's - like
>> the Platforms do.  The OS plugins deal with internal data structures, which
>> tend to change fairly frequently.  So trying to package them with lldb
>> doesn't seem supportable.
>> By making the OS plugin something that comes from outside lldb, we allow
>> the kernel developers to provide this knowledge on demand.  That is very
>> convenient.  For instance, on macOS, the dSYM bundle for the mach kernel
>> contains the Operating System plugin for that kernel.  When lldb is used
>> for kernel debugging, it finds the dSYM associated with the kernel it is
>> targeting and loads in the python support from the dSYM. That way it is
>> ensured to get the correct plugin for that kernel.  It also means that lldb
>> can support kernel versions that didn't even exist when it was made.
>> As for why this is done with Python and not the C++ SB API's, there's
>> nothing to stop it from also being in C++, you can actually write loadable
>> C++ plugins with the SB API's for data formatters, for instance.   But
>> there's generally no significant performance advantage to doing that, and
>> its less convenient, so there just hasn't been much demand for it.
>> Jim
>> > On Dec 19, 2018, at 12:44 PM, Alexander Polyakov via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>> >
>> > Hi lldb-dev,
>> >
>> > Could someone explain me why do we use python (OperatingSystemPython)
>> to describe OS objects like threads? What are the advantages of such an
>> approach in comparison to C++ used in Platform plugin for example? IMO, the
>> OperatingSystem plugin could be more like the Platform one, it could have a
>> separate directory for each OS with its own implementation inside.
>> >
>> > --
>> > Alexander
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> --
> Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20181226/4f6e003d/attachment.html>

More information about the lldb-dev mailing list