Gentle ping. On Thu, Dec 20, 2018 at 6:00 PM Alexander Polyakov <polyakov....@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 <jing...@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@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 >> >> > > -- > Alexander > -- Alexander
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
