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

[Aleksandr Urakov via lldb-dev]

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

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

[Kristof Beyls via lldb-dev]

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 Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products” if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

In the original post, there was a suggestion to bring back the "UNCONFIRMED" 
status. I think that'd be a great idea, as it both makes it easy to search for 
untriaged bugs and to give feedback to a reporter that their bug is real and 
acknowledged. Is that planned?

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) 
the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.
However, I also think it’s a good idea, so I’ll investigate in more detail now 
if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I 
believe I’ll have to give all existing users the rights to be able to confirm 
bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now 
plan to do so, and will adapt the proposed documentation at 
https://reviews.llvm.org/D53691 accordingly.
Thanks for pointing to this!

Just a status update on investigations to enable the UNCONFIRMED/CONFIRMED 
states: it seems that bugzilla by-default will put bugs in the “CONFIRMED” 
state when creating new bugs, if the reporter has “can-confirm” rights. I 
believe our de facto policy is for everyone with an account to be able to 
confirm bugs. Also, you need an account to be able to report a bug. The result 
is that all new bugs by default will go to status “CONFIRMED”, unless the 
reporter carefully remembers to change the default and select “UNCONFIRMED”. 
(Also see https://bugzilla.mozilla.org/show_bug.cgi?id=915682 which suggests 
this behaviour is not configurable).

Unless that can be solved, I fear that many bugs will be reported with the 
default “CONFIRMED” status even though they aren’t triaged yet. I believe that 
is worse than the current default “NEW” state.

The only work around for this behaviour where we still get a “to be triaged” 
state I can think of at the moment is to introduce a custom “CONFIRMED” status, 
not using bugzilla’s built-in special “UNCONFIRMED” support and have a flow 
that would allow something like:

NEW -> CONFIRMED -> ASSIGNED -> RESOLVED -> …

The advantage is we’d have separate states to represent “this bug was raised” 
(NEW) vs “this bug was triaged & confirmed” (CONFIRMED).
The disadvantage is that we’ll start deviating from the default bugzilla 
workflows.

Overal

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

[Zachary Turner via lldb-dev]

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

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

[Aleksandr Urakov via lldb-dev]

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

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

[Zachary Turner via lldb-dev]

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

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

[Tom Stellard via lldb-dev]

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 Smith >>> > wrote:

 On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
 mailto:cfe-...@lists.llvm.org>> wrote:

> On 5 Oct 2018, at 07:04, Dean Michael Berris  > wrote:
>
> Thank you for starting this conversation! I look forward to the 
> results of the BoF discussion summarised as well.

 Dean, all,

 There was a lively discussion at the BoF; we’ve tried to take notes at 
 https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to 
 capture all the points. The slides used to kick start the discussion can 
 be found at 
 https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

 Both at the BoF and in the mail thread, there have been many 
 suggestions for improvements. So many that if we’d want to introduce all 
 of them at once, we’d probably get stuck and not introduce any. To try and 
 make progress on the ones I myself feel are most useful, I’ve volunteered 
 for 2 actions:

 1. Write up a proposal for documentation on what to do during bug 
 triaging/closing/etc. I’ve just done so and put it up for review at 
 https://reviews.llvm.org/D53691.
 2. Write an email to the mailing lists to ask for volunteers for being 
 on the “default-cc” list for components, implying you’re willing to triage 
 bugs reported against those components. I’ve decided to first try and get 
 consensus on what is expected when triaging a bug (see point above) before 
 actively searching for volunteers for all components. That being said, 
 both at the dev meeting and in the days after, I already received many 
 requests from people to be added to the default-cc list for specific 
 components. Of course, I’m very happy to add people volunteering to 
 default-cc lists, so if you don’t want to wait to get added to a 
 default-cc list, please email bugs-ad...@lists.llvm.org 
  or raise it as a ticket in 
 bugs.llvm.org  under “Bugzilla Admin”/“Products”.

 Furthermore, since the BoF, I’ve seen a quite a few requests to clean 
 up and introduce new components in Bugzilla. We’ve implemented the changes 
 quickly and will aim to continue to have a quick response time in the 
 future. Please file a ticket in bugs.llvm.org  
 under “Bugzilla Admin”/“Products” if you want to request a specific change.

 For most of the other points that were raised: I don’t currently plan 
 on acting on them immediately myself and hope to first see an impact of 
 the above actions.


 In the original post, there was a suggestion to bring back the 
 "UNCONFIRMED" status. I think that'd be a great idea, as it both makes it 
 easy to search for untriaged bugs and to give feedback to a reporter that 
 their bug is real and acknowledged. Is that planned?
>>>
>>> I hadn’t seen too much feedback on the idea for introducing 
>>> (reintroducing?) the “UNCONFIRMED” status, so hadn’t planned on making 
>>> changes to that now.
>>> However, I also think it’s a good idea, so I’ll investigate in more detail 
>>> now if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. 
>>> I believe I’ll have to give all existing users the rights to be able to 
>>> confirm bugs). If the “UNCONFIRMED” status can be introduced relatively 
>>> easily, I now plan to do so, and will adapt the proposed documentation at 
>>> https://reviews.llvm.org/D53691 accordingly.
>>> Thanks for pointing to this!
>>
>> Just a status update on investigations to enable the UNCONFIRMED/CONFIRMED 
>> states: it seems that bugzilla by-default will put bugs in the “CONFIRMED” 
>> state when creating new bugs, if the reporter has “can-confirm” rights. I 
>> believe our de facto policy is for everyone with an account to be able to 
>> confirm bugs. Also, you need an account to be able to report a bug. The 
>> result is that all new bugs by default will go to status “CONFIRMED”, unless 
>> the reporter carefully remembers to change the default and select 
>> “UNCONFIRMED”. (Also see https://bugzilla.mozilla.org/show_bug.cgi?id=915682 
>> which suggests this behaviour is not configurable).
>>
>> Unless that can be solved, I fear that many bugs will be reported with the 
>> default “CONFIRMED” status even though they aren’t triaged yet. I believe 
>> that is worse than the current default “NEW” state.
>>
>> The only work around for this behaviour where we still get

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

[Richard Smith via lldb-dev]

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 that is sufficient.
>
I don't agree. That is the status quo and it doesn't work. Sending email to
only one person when a bug is updated is really not much better than
sending email to no-one. It's unreasonable to expect a single person to
triage all bugs in a component or product.

Auto-cc also makes it impractical to track particular bugs one is actually
especially interested in. It's just not a good solution.

Having one bugs list per product, that receives email for all bug updates
in that product, would seem like a decent solution. That way the various
maintainers for that product can all subscribe and use their normal mail
filters to classify the mail.

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.

> Also +1 for UNCONFIRMED.
>
> --paulr
>
>
>
> *From:* Kristof Beyls [mailto:kristof.be...@arm.com]
> *Sent:* Friday, October 26, 2018 10:26 AM
> *To:* Richard Smith
> *Cc:* dean.ber...@gmail.com; llvm-dev; LLDB Dev; Clang Dev; Tanya
> Lattner; nd; Robinson, Paul
> *Subject:* Re: [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging
>
>
>
>
>
>
>
> On 26 Oct 2018, at 04:26, Richard Smith  wrote:
>
>
>
> On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
> On 5 Oct 2018, at 07:04, Dean Michael Berris 
> wrote:
>
>
> Thank you for starting this conversation! I look forward to the results of
> the BoF discussion summarised as well.
>
>
>
> Dean, all,
>
>
>
> There was a lively discussion at the BoF; we’ve tried to take notes at
> https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to
> capture all the points. The slides used to kick start the discussion can be
> found at
> https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit
>
>
>
> Both at the BoF and in the mail thread, there have been many suggestions
> for improvements. So many that if we’d want to introduce all of them at
> once, we’d probably get stuck and not introduce any. To try and make
> progress on the ones I myself feel are most useful, I’ve volunteered for 2
> actions:
>
>
>
> 1. Write up a proposal for documentation on what to do during bug
> triaging/closing/etc. I’ve just done so and put it up for review at
> https://reviews.llvm.org/D53691.
>
> 2. Write an email to the mailing lists to ask for volunteers for being on
> the “default-cc” list for components, implying you’re willing to triage
> bugs reported against those components. I’ve decided to first try and get
> consensus on what is expected when triaging a bug (see point above) before
> actively searching for volunteers for all components. That being said, both
> at the dev meeting and in the days after, I already received many requests
> from people to be added to the default-cc list for specific components. Of
> course, I’m very happy to add people volunteering to default-cc lists, so
> if you don’t want to wait to get added to a default-cc list, please email
> bugs-ad...@lists.llvm.org or raise it as a ticket in bugs.llvm.org under
> “Bugzilla Admin”/“Products”.
>
>
>
> Furthermore, since the BoF, I’ve seen a quite a few requests to clean up
> and introduce new components in Bugzilla. We’ve implemented the changes
> quickly and will aim to continue to have a quick response time in the
> future. Please file a ticket in bugs.llvm.org under “Bugzilla
> Admin”/“Products” if you want to request a specific change.
>
>
>
> For most of the other points that were raised: I don’t currently plan on
> acting on them immediately myself and hope to first see an impact of the
> above actions.
>
>
>
> In the original post, there was a suggestion to bring back the
> "UNCONFIRMED" status. I think that'd be a great idea, as it both makes it
> easy to search for untriaged bugs and to give feedback to a reporter that
> their bug is real and acknowledged. Is that planned?
>
>
>
> I hadn’t seen too much feedback on the idea for introducing
> (reintroducing?) the “UNCONFIRMED” status, so hadn’t planned on making
> changes to that now.
>
> However, I also think it’s a good idea, so I’ll investigate in more detail
> now if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g.
> I believe I’ll have to give all existing users the rights to be able to
> confirm bugs). If the “UNCONFIRMED” status can be introduced relatively
> easily, I now plan to do so, and will adapt the proposed documentation at
> https://reviews.llvm.org/D53691 accordingly.
>
> Thanks for pointing to this!
>
>
>
> Also, a big problem with bugzilla as we 

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

[David Greene via lldb-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* attention
> than non-bug development discussion.

Some of us are on space-limited machines (I'm thinking of personal
equipment, not corporate infrastructure) and getting all bug updates for
components could put a real squeeze on things.

I agree that cfe-bugs, for example, should get copied on all updates but
those updates should be opt-in.

 -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

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 
>  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 
>  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 
>  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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Richard Smith via lldb-dev]

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* attention
> > than non-bug development discussion.
>
> Some of us are on space-limited machines (I'm thinking of personal
> equipment, not corporate infrastructure) and getting all bug updates for
> components could put a real squeeze on things.
>
> I agree that cfe-bugs, for example, should get copied on all updates but
> those updates should be opt-in.
>

Assuming we go that way, do you think it's reasonable for someone to want
to subscribe to cfe-dev but not cfe-bugs? What's the use case for that? If
it's email volume, that choice would prioritize the discussion of "I'm not
sure this is a bug" or "what's going on here?" plus general dev discussion
and announcements (cfe-dev) over the discussion of "I'm confident that this
is a bug" (cfe-bugs).

Perhaps we should have a separate cfe-announce list for people who want to
stay informed but not drink from the firehose of development discussion
(current cfe-dev plus clang bug updates).

 -David
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
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

[Leonard Mosescu via lldb-dev]

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
>
>
___
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]

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  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

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

[via lldb-dev]

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 week. We don't know how it's working yet.  The status 
quo is people willing to subscribe to llvm-bugs, and as for myself, I probably 
care about 1% of the bugs ever filed.  In the bug BoF, very few people present 
subscribed to llvm-bugs, with at least one non-subscriber proclaiming he didn't 
want the extra traffic.

I agree that cfe-bugs, for example, should get copied on all updates but
those updates should be opt-in.

Assuming we go that way, do you think it's reasonable for someone to want to 
subscribe to cfe-dev but not cfe-bugs? What's the use case for that?

The use case is people who are doing their own projects, not working on the 
Clang front-end itself.  There's clearly a non-trivial percentage of dev 
subscribers in that category.  I feel a need to keep up with what's happening 
but it's extremely rarely that I'll ever be moved to try to fix a Clang bug.
--paulr

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Zachary Turner via lldb-dev]

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 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
go one step further and unsubscribe from llvm-dev.


Slightly unrelated, but has there been any specific guidance or proposals
of how to re-organize the components?   They all look way too specific to
me.  For example, in clang we have:

C++
C++17
C++11
C++14
C++2a
CUDA
Documentation
Driver
Formatter
Frontend
Headers
libclang
LLVM Codegen
Modules
OpenCL
Static Analyzer
Tooling.

Can we cut this down to about 4?  I'll take a stab at it:

Standards Conformance
Tooling
Codegen Quality
Other

I don't actively work on clang so feel free to ignore this, it's just a
strawman attempt at doing something.

The motivation here is that if people can quickly and easily identify the
set of components they're interested in they are more willing to subscribe
themselves to those components.

I'm guessing that of the existing set of components, there is a significant
amount of overlap among the set of components that individual contributors
are interested in, which suggests we can compress most of them down quite a
bit.

On Wed, Oct 31, 2018 at 11:25 AM Richard Smith via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Wed, 31 Oct 2018, 10:47 David Greene via cfe-dev <
> cfe-...@lists.llvm.org wrote:
>
>> 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 are on space-limited machines (I'm thinking of personal
>> equipment, not corporate infrastructure) and getting all bug updates for
>> components could put a real squeeze on things.
>>
>> I agree that cfe-bugs, for example, should get copied on all updates but
>> those updates should be opt-in.
>>
>
> Assuming we go that way, do you think it's reasonable for someone to want
> to subscribe to cfe-dev but not cfe-bugs? What's the use case for that? If
> it's email volume, that choice would prioritize the discussion of "I'm not
> sure this is a bug" or "what's going on here?" plus general dev discussion
> and announcements (cfe-dev) over the discussion of "I'm confident that this
> is a bug" (cfe-bugs).
>
> Perhaps we should have a separate cfe-announce list for people who want to
> stay informed but not drink from the firehose of development discussion
> (current cfe-dev plus clang bug updates).
>
>  -David
>
>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
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

[Zachary Turner via lldb-dev]

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 
> 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
>
___
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]

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
> 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 
>> 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

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

[via lldb-dev]

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 go one step 
further and unsubscribe from llvm-dev.

FTR that's roughly the same volume as llvm-dev for October already has.  So 
cc'ing llvm-dev on all bugs would basically double the volume.
Actually more than double, if we also start emailing every comment on every bug.
--paulr
___
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

[Leonard Mosescu via lldb-dev]

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  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 
> 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 
>>> 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

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

[Jim Ingham via lldb-dev]

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 
>  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  
> 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  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 
>  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  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 
>  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 
> exten

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

[Alexander Polyakov via lldb-dev]

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 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 
> 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 
> 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 provid

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

[Jim Ingham via lldb-dev]

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 
> >  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 
> >  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  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 
> >  wrote:
> > Hi Leonar

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

[Jim Ingham via lldb-dev]

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 
>  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 
>>>  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 
>>>  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 Turn