Re: [lldb-dev] [RFC] OS awareness in LLDB

> > Are you asking for the ability to create external native plug-ins instead > of the python OS plug-in interface? The main idea is to have one common native/Python OS plug-in that can be extended with new architectures and operating systems. What is missing from the python OS plug-in interface

Re: [lldb-dev] [RFC] OS awareness in LLDB

> On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev > wrote: > > Hi lldb-dev, > > Currently I'm working on an OS plug-in for multiple operating systems and > architectures, during my work, I noted a few moments I want to discuss with > the community. > > 1) Adding RegisterContex

Re: [lldb-dev] [RFC] OS awareness in LLDB

Gentle ping. On Wed, Apr 3, 2019 at 8:05 PM Alexander Polyakov wrote: > Hi lldb-dev, > > Currently I'm working on an OS plug-in for multiple operating systems and > architectures, during my work, I noted a few moments I want to discuss with > the community. > > 1) Adding RegisterContext to SB AP

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

Hi lldb-dev, Currently I'm working on an OS plug-in for multiple operating systems and architectures, during my work, I noted a few moments I want to discuss with the community. 1) Adding RegisterContext to SB API: if you want your OS plug-in to support multiple architectures you need to impl

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

> On Nov 11, 2018, at 10:30 AM, Alexander Polyakov > wrote: > > The data formatter in lldb is a subsystem that allows users to define custom > display options, the Platform is the agent that provides a way to work with a > specific platform. I agree that we need the Platform to provide the O

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

The data formatter in lldb is a subsystem that allows users to define custom display options, the Platform is the agent that provides a way to work with a specific platform. I agree that we need the Platform to provide the OS specific data formatters, but also the Platform should have a functionali

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

I don’t think we are disagreeing, probably I was just being a little too terse. What I’m saying is that to PRESENT a mutex in some detail, we need an OS specific data formatter, so in that case, we just need some agent, either the Platform or the SystemRuntime (but the Platform seems better to

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

I'm new in plugin ecosystem, so I have some misunderstanding. You wrote that to comprehend mutexes we just need a data formatter, but how can we get the raw data of all mutexes in our OS? I thought I was supposed to write a generic code that will use a user-defined (specific for each OS) way to col

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

As Jason pointed out, we also have the SystemRuntime Plugin. That is intended to provide extra runtime available information based on the current system. For instance, on Darwin we use it to present the libdispatch queue view of threads on the system, and to decorate threads that are doing wor

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

Right now, the OS plugin only supports the job of adding threads. And that makes more sense as a plugin, because for instance if you had a cooperative threading scheme that you were laying on top of the system threads in a User Space process, you can use the Operating System plugin to show you

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

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 : > lldb has one feature - the "Operating System Plugin" that is specifically > designed for debugging threads in kernel contexts. The OS plugin

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

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 embedd

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

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 debug

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

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 wrote: > I don’t totally agree with this. I think there are a lot of useful os >

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

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

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

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 suppor

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

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 surprisi

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

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 semaphore