[lldb-dev] [RFC] OS Awareness in LLDB

Wed Oct 31 15:44:23 PDT 2018

So, if I understand you write, I can look at OS plugin and add a support of
mutexes or memory pages for example?

чт, 1 нояб. 2018 г. в 1:05, Jim Ingham <jingham at apple.com>:

> lldb has one feature - the "Operating System Plugin" that is specifically
> designed for debugging threads in kernel contexts.  The OS plugin allows a
> kernel to present it's notion of threads into lldb_private::Threads.  The
> xnu kernel macros have an implementation of this, as do some other embedded
> OS'es.  lldb actually gets used pretty extensively for debugging xnu - the
> Darwin kernel.
>
> Kuba is adding the notion of "Frame recognizers" which can give
> significance to particular functions when they appear on the stack (for
> instance displaying the first argument of read, etc. as a file handle even
> if you have no debug information for it.)  That's another way that you
> could express your understanding of the OS you are running on for debugger
> users.  Greg wrote a data formatter for the Darwin implementation of
> pthread_mutex that shows the thread that has the lock and some other
> information like that.  So data formatters are also a way lldb can express
> knowledge of the host OS.
>
> Jim
>
> > On Oct 31, 2018, at 12:52 PM, Leonard Mosescu via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> > Conceptually it's different levels of abstraction: a user-mode debugger
> handles processes, threads as first class concepts. In kernel-mode (or
> kernel land), these are just data structures that the code (the kernel) is
> managing. From a more pragmatic perspective, the difference is in where the
> debugging hooks are implemented and what interfaces are exposed (for
> example a kernel mode debugger can normally "poke" around any piece of
> memory and it has to be aware of things like VA mappings, while a user-mode
> debugger is only allowed to control a limited slice of the system - ex.
> control a sub-process through something like ptrace)
> >
> > Unless you're specifically looking at kernel debugging I'd stay away
> from that. For one thing, LLDB is mostly used as an user-mode debugger so
> the impact of any improvements would be bigger.
> >
> > Regarding the value of OS-awareness for user-mode debugging, I agree
> with Zach - for example windbg provides both kernel mode and user mode
> !locks commands. The only suggestion I'd add is to consider an expanded
> view of the "OS" to include runtime components which may not be technically
> part of what most people think of as the "OS": user-mode loaders and high
> level things like std::mutex, etc.
> >
> > On Wed, Oct 31, 2018 at 12:29 PM, Alexander Polyakov <
> polyakov.alx at gmail.com> wrote:
> > Looks like I don't completely understand what is the difference between
> user-mode and kernel-mode from the debugger's point of view. Could you
> please explain me this?
> >
> > On Wed, Oct 31, 2018 at 10:22 PM Zachary Turner <zturner at google.com>
> wrote:
> > I don’t totally agree with this. I think there are a lot of useful os
> awareness tasks in user mode. For example, you’re debugging a deadlock and
> want to understand the state of other mutexes, who owns them, etc. or you
> want to examine open file descriptors. In the case of a heap corruption you
> may wish to study the internal structures of your process’s heap, or even
> lower level, the os virtual memory page table structures.
> >
> > There’s quite a lot you can still do in user mode, but definitely there
> is more in kernel mode. As Leonard said, try put WinDbg as a lot of this
> stuff already exists so it’s a good reference
> > On Wed, Oct 31, 2018 at 12:08 PM Alexander Polyakov via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > Hi Leonard,
> >
> > I think it will be kernel-mode debugging since debugging an application
> in user mode is not an OS awareness imo. Of course, some of kernel's
> modules might run in user-mode, but it will be ok I think.
> >
> > Thanks for your reference, I'll take a look at it.
> >
> > Also, I found out that ARM supports OS awareness in their DS-5 debugger.
> They have a mechanism for adding new operating systems. All you need to do
> is to describe OS' model (thread's or task's structure for example). I
> think that is how it might be done in LLDB.
> >
> > On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu <mosescu at google.com>
> wrote:
> > Hi Alexander, are you interested in user-mode, kernel-mode debugging or
> both?
> >
> > Fore reference, the current state of the art regarding OS-awareness
> debugging is debugging tools for windows (windbg & co.). This is not
> surprising since the tools were developed alongside Windows. Obviously they
> are specific to Windows, but it's good example of how the OS-awareness
> might look like.
> >
> >
> > On Mon, Oct 29, 2018 at 11:37 AM, Alexander Polyakov via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> > Hi lldb-dev,
> >
> > I'm a senior student at Saint Petersburg State University. The one of my
> possible diploma themes is "OS Awareness in LLDB". Generally, the OS
> awareness extends a debugger to provide a representation of the OS threads
> - or tasks - and other relevant data structures, typically semaphores,
> mutexes, or queues.
> >
> > I want to ask the community if OS awareness is interesting for LLDB
> users and developers? The main goal is to create some base on top of LLDB
> that can be extended to support awareness for different operating systems.
> >
> > Also, if you have a good article or other useful information about OS
> awareness, please share it with me.
> >
> > Thanks in advance!
> >
> > --
> > Alexander
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > Alexander
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > --
> > Alexander
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> --
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20181101/4edbcbfe/attachment.html>