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@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
