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] [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

On the other hand, I'm intentionally unsubscribed from llvm-bugs because it just generates an unbelievable volume of email. Checking the archives, there were over 700 emails in October. I'm just not going to sign up for that, and if all llvm bugs started going to llvm-dev I would probably even

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] [cfe-dev] [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

I can tell you that in LLDB we already do get CC'ed on the list for every bug. I will grant you that the volume of bugs in LLDB is much lower than other lists, but I find it very helpful. It gives visibility to bugs that would otherwise be seen by nobody. On the other hand, I'm intentionally uns

Re: [lldb-dev] [cfe-dev] [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

If the admins guarantee that there is at least one auto-cc (who promises to pay attention) for each component, I think that is sufficient. I don't agree. That is the status quo and it doesn't work. No, it's not the status quo, because we've only started soliciting auto-cc subscribers in the past

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

On Wed, 31 Oct 2018, 10:47 David Greene via cfe-dev Richard Smith via cfe-dev writes: > > > In fact, I think it'd be entirely reasonable to subscribe cfe-dev to > > all clang bugs (fully subscribe -- email on all updates!). I don't see > > any reason whatsoever why a bug update should get *less*

Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives

We need to do more work to make sure the "language" setting for expressions gets propagated everywhere and obeyed. We could also be smarter about setting the default. It seems fine to me for lldb to assume - if we know nothing different - that we should use ObjC++ as the language to compile ex

Re: [lldb-dev] [cfe-dev] [llvm-dev] [RFC] LLVM bug lifecycle BoF - triaging

Richard Smith via cfe-dev writes: > In fact, I think it'd be entirely reasonable to subscribe cfe-dev to > all clang bugs (fully subscribe -- email on all updates!). I don't see > any reason whatsoever why a bug update should get *less* attention > than non-bug development discussion. Some of us

Re: [lldb-dev] [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

On Fri, 26 Oct 2018, 08:12 via llvm-dev As an llvm-bugs subscriber, I would prefer *not* to have email for every > comment to every bug. That's what the CC list is for. > > If the admins guarantee that there is at least one auto-cc (who promises > to pay attention) for each component, I think tha

Re: [lldb-dev] [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

On 10/31/2018 06:27 AM, Kristof Beyls wrote: > > >> On 26 Oct 2018, at 17:26, Kristof Beyls > > wrote: >> >> >> >>> On 26 Oct 2018, at 16:25, Kristof Beyls via llvm-dev >>> mailto:llvm-...@lists.llvm.org>> wrote: >>> >>> >>> On 26 Oct 2018, at 04:26, Richard Sm

Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives

The first thing I would try is to see where the language is getting set to objective c and force it c++. Just as an experiment. Depending where it happens, it may be possible to initialize it from the debug info (or hardcode it). But since ObjC assumptions are baked into several places, this has p

Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives

Sorry, I have somehow missed the discussion continuation there. Yes, it's a very similar problem, thanks. But unfortunately no one of the workarounds mentioned there doesn't work in this situation... On Wed, Oct 31, 2018 at 4:32 PM Zachary Turner wrote: > It seems like we hit this issue in diffe

Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives

It seems like we hit this issue in different contexts almost at the same time (see my thread several days ago about “problem formatting value objects”). That might at least give you some context about why things I wish ObjC assumptions weren’t so deeply embedded, but alas it is the case. Hopefull

Re: [lldb-dev] [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

On 26 Oct 2018, at 17:26, Kristof Beyls mailto:kristof.be...@arm.com>> wrote: On 26 Oct 2018, at 16:25, Kristof Beyls via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote: On 26 Oct 2018, at 04:26, Richard Smith mailto:rich...@metafoo.co.uk>> wrote: On Thu, 25 Oct 2018 at 05:10, Kristof

Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives

Hello, I've tried to use a check like `if (m_ast_context->getLangOpts().ObjC) ...`, but it seems that it's always true. How can we else determine here if the Objective-C case is used? Or if we can't, where can we move `if (name == id_name || name == Class_name)` to make it Objective-C only? What r