[lldb-dev] OperatingSystem plugin

[Alexander Polyakov via lldb-dev]

Gentle ping.

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

> 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
>


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