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@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....@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 <ztur...@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@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 <mose...@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@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@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 > > > -- > 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
