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

[Aleksandr Urakov via lldb-dev]

Thanks for details! So at first I'll try to propagate the "language"
setting of an expression there.

On Wed, Oct 31, 2018 at 9:04 PM Jim Ingham  wrote:

> 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 expressions.  That
> makes sense for most developers, since it only has a few collisions (Class
> and id) that seldom cause problems IRL and gives the widest coverage for of
> expressions.  BUT... the behavior when compiling an expression should be
> determined by the expression's language  rather than how we set up the
> target ScratchASTContext.
>
> So for instance, if you do:
>
> (lldb) expression --language c++ -- id
>
> that should work, though without the --language you would get an error.
> That doesn't currently work, so apparently we aren't always checking the
> language of the expression.
>
> The situation is a little more complicated than that because sometimes we
> check the frame's language (e.g. we do that in AddLocalVariableDecls, w/o
> checking whether the expression has a specific language.  So this
> definitely needs cleaning up.
>
> Then we should also let the Language Runtime's adjust the default
> language, so if you have a program that doesn't load the ObjC runtime, we
> set the default language to C++, not ObjC++.
>
> But the first stage is to make sure we are paying attention to the
> explicit language of the expression throughout the expression parser code.
>
> Jim
>
>
> > On Oct 31, 2018, at 7:25 AM, Zachary Turner  wrote:
> >
> > 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
> potential to break some things
> > On Wed, Oct 31, 2018 at 6:54 AM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
> > 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 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.
> >
> > Hopefully Jim or someone has ideas on how to fix this properly.
> > On Wed, Oct 31, 2018 at 5:08 AM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
> > 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
> regressions Objective-C users would have if we would remove this check from
> here?
> >
> > Regards,
> > Alex
> >
> > On Wed, Oct 24, 2018 at 7:14 PM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
> > Hi all!
> >
> > There are two hardcoded names to ignore in the
> `ClangASTSource::IgnoreName` function, "Class" and "id", they are valid
> names for C++. It seems that they were added for the Objective-C case. But
> the problem is that when they are in locals they are blocking expressions
> evaluation.
> >
> > For example for the next code:
> > int main() {
> >   int x = 5;
> >   int id = 7;
> >   int y = 8;
> >   return 0;
> > }
> > if you'll break on `return 0` and will try to `print x`, then you'll get
> a error like `no member named 'id' in namespace '$__lldb_local_vars'`.
> >
> > Do you have any ideas, how can we fix it?
> >
> > Regards,
> > Alex
> >
> >
> > --
> > Aleksandr Urakov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
> >
> >
> > --
> > Aleksandr Urakov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
>
>

-- 
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Alexander Polyakov via lldb-dev]

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 collect all mutexes and then use some data formatter to show them.

On Thu, Nov 1, 2018 at 2:31 AM Jim Ingham  wrote:

> 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 work on behalf of some queue with the state of the thread
> that enqueued the work at the time the work  item was enqueued.
>
> If for instance you had a way to gather all the locks in the process
> (something we've been asked to do but I don't know how to do it on
> Darwin...), that would be the place to put that functionality.
>
> Jim
>
>
> > On Oct 31, 2018, at 4:05 PM, Jim Ingham via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > 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 the cooperative threads.  This is not an abstract example...  I
> think it should stay with just that job.
> >
> > The place where lldb holds this sort of knowledge is supposed to be in
> the Platform class.  So for instance, to comprehend mutexes you really just
> need a data formatter.  The trick is that it has to be a data formatter
> that is provided by the platform.  Similarly you want to have frame
> recognizers for interesting lower-level calls in the system.  The machinery
> will shortly be there to do that, but loading the particular recognizers
> will either need to be done by hand, or coordinated by the Platform.  In
> general, I think most of the kinds of re-presentation you need to do to
> make OS objects and processes more comprehensible can be built as general
> mechanisms like the above.  Then the Platform can coordinate providing the
> set of more general transformations that are appropriate to the Platform
> you are targeting.
> >
> > Jim
> >
> >
> >
> >> On Oct 31, 2018, at 3:44 PM, Alexander Polyakov 
> wrote:
> >>
> >> 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 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 t

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

[Jim Ingham via lldb-dev]

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 me for this) to 
provide the OS specific data formatters.  But we don’t need a new facility for 
that, just a way to dial up the right OS-specific instances.  And if we can 
reuse more general features to present this sort of OS specific info we are 
better off; it reduces lldb’s surface area and provides facilities we might 
find other neat ways to use.

OTOH, for a runtime feature like “Gather all the mutexes currently in flight” 
we would need some new code.  There’s nothing in lldb that does that sort of 
job.  The SystemRuntime seems like the right place for that code to go.

Jim


> On Nov 1, 2018, at 1:25 AM, Alexander Polyakov  wrote:
> 
> 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 
> collect all mutexes and then use some data formatter to show them.
> 
> On Thu, Nov 1, 2018 at 2:31 AM Jim Ingham  > wrote:
> 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 work on 
> behalf of some queue with the state of the thread that enqueued the work at 
> the time the work  item was enqueued.
> 
> If for instance you had a way to gather all the locks in the process 
> (something we've been asked to do but I don't know how to do it on 
> Darwin...), that would be the place to put that functionality.
> 
> Jim
> 
> 
> > On Oct 31, 2018, at 4:05 PM, Jim Ingham via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> > 
> > 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 the 
> > cooperative threads.  This is not an abstract example...  I think it should 
> > stay with just that job.
> > 
> > The place where lldb holds this sort of knowledge is supposed to be in the 
> > Platform class.  So for instance, to comprehend mutexes you really just 
> > need a data formatter.  The trick is that it has to be a data formatter 
> > that is provided by the platform.  Similarly you want to have frame 
> > recognizers for interesting lower-level calls in the system.  The machinery 
> > will shortly be there to do that, but loading the particular recognizers 
> > will either need to be done by hand, or coordinated by the Platform.  In 
> > general, I think most of the kinds of re-presentation you need to do to 
> > make OS objects and processes more comprehensible can be built as general 
> > mechanisms like the above.  Then the Platform can coordinate providing the 
> > set of more general transformations that are appropriate to the Platform 
> > you are targeting.
> > 
> > Jim
> > 
> > 
> > 
> >> On Oct 31, 2018, at 3:44 PM, Alexander Polyakov  >> > wrote:
> >> 
> >> 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 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] [Bug 39529] New: Stride Step – stepping multiple lines at once without missing anything

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=39529

Bug ID: 39529
   Summary: Stride Step – stepping multiple lines at once without
missing anything
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: d...@yost.com
CC: llvm-b...@lists.llvm.org

I filed a feature request with IDEA, Xcode, and Visual Studio. Clearly llvm and
gdb will have to implement the underlying mechanism, so I'll just leave this
here.

https://youtrack.jetbrains.com/issue/IDEA-192473

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev