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 <jing...@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@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 > > -- Alexander
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
