Re: [lldb-dev] OperatingSystem plugin

2018-12-26 Thread Alexander Polyakov via lldb-dev
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

Re: [lldb-dev] OperatingSystem plugin

2018-12-20 Thread 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

Re: [lldb-dev] OperatingSystem plugin

2018-12-19 Thread Jim Ingham via lldb-dev
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 t

[lldb-dev] OperatingSystem plugin

2018-12-19 Thread Alexander Polyakov via lldb-dev
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 coul