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