<div><div dir="auto">So, if I understand you write, I can look at OS plugin and add a support of mutexes or memory pages for example?</div></div><div><br><div class="gmail_quote"><div dir="ltr">чт, 1 нояб. 2018 г. в 1:05, Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Jim<br>
<br>
> On Oct 31, 2018, at 12:52 PM, Leonard Mosescu via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> 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)<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> On Wed, Oct 31, 2018 at 12:29 PM, Alexander Polyakov <<a href="mailto:polyakov.alx@gmail.com" target="_blank">polyakov.alx@gmail.com</a>> wrote:<br>
> 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?<br>
> <br>
> On Wed, Oct 31, 2018 at 10:22 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> 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.<br>
> <br>
> 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 <br>
> On Wed, Oct 31, 2018 at 12:08 PM Alexander Polyakov via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> Hi Leonard,<br>
> <br>
> 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.<br>
> <br>
> Thanks for your reference, I'll take a look at it. <br>
> <br>
> 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.<br>
> <br>
> On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu <<a href="mailto:mosescu@google.com" target="_blank">mosescu@google.com</a>> wrote:<br>
> Hi Alexander, are you interested in user-mode, kernel-mode debugging or both?<br>
> <br>
> 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.<br>
> <br>
> <br>
> On Mon, Oct 29, 2018 at 11:37 AM, Alexander Polyakov via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> Hi lldb-dev,<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Also, if you have a good article or other useful information about OS awareness, please share it with me.<br>
> <br>
> Thanks in advance!<br>
> <br>
> -- <br>
> Alexander<br>
> <br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> Alexander<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
> <br>
> <br>
> -- <br>
> Alexander<br>
> <br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12.8px">Alexander</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>