[lldb-dev] OperatingSystem plugin

[Alexander Polyakov via lldb-dev]

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/20181220/f9a33da1/attachment.html>