Re: [lldb-dev] I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

[Leonard Mosescu via lldb-dev]

Thank you Jim! I'm at cppcon and I won't be able to work on it until
Monday, but I can help with a code review if you're planning to take a stab
at it.

I was hoping we can avoid dealing with reentrancy but I was wrong. For
handling reentrancy I was briefly considering either maintaining a full
blown command stack or perhaps just a nesting counter.

Also, with reentrancy, I think that interruption should affect the
"outmost" command scope rather than just interrupting the current command,
what do you think?




On Wed, Sep 27, 2017 at 6:46 PM, Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> This actually asserts on any use "command source" is the one command that
> re-enters the command interpreter.  It should be as simple as getting
> command source to rest the state flag before it goes to do the sourcing.
> I'll check that out tomorrow if nobody gets to it first.
>
> command source is one of a set of early commands that we got into lldb
> before we had hired the person who wrote the testsuite way way back in the
> day, and though we went and backfilled the tests at that point, apparently
> we missed command source.  So we'll also have to add a test for that.
>
> I also filed:
>
> https://bugs.llvm.org/show_bug.cgi?id=34758
>
> to cover the issue.
>
> Jim
>
> ___
> 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] I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

[Greg Clayton via lldb-dev]

We should probably have a stack that we can push and pop these states?

> On Sep 28, 2017, at 10:59 AM, Leonard Mosescu via lldb-dev 
>  wrote:
> 
> Thank you Jim! I'm at cppcon and I won't be able to work on it until Monday, 
> but I can help with a code review if you're planning to take a stab at it.
> 
> I was hoping we can avoid dealing with reentrancy but I was wrong. For 
> handling reentrancy I was briefly considering either maintaining a full blown 
> command stack or perhaps just a nesting counter.
> 
> Also, with reentrancy, I think that interruption should affect the "outmost" 
> command scope rather than just interrupting the current command, what do you 
> think?
> 
> 
> 
> 
> On Wed, Sep 27, 2017 at 6:46 PM, Jim Ingham via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> This actually asserts on any use "command source" is the one command that 
> re-enters the command interpreter.  It should be as simple as getting command 
> source to rest the state flag before it goes to do the sourcing.  I'll check 
> that out tomorrow if nobody gets to it first.
> 
> command source is one of a set of early commands that we got into lldb before 
> we had hired the person who wrote the testsuite way way back in the day, and 
> though we went and backfilled the tests at that point, apparently we missed 
> command source.  So we'll also have to add a test for that.
> 
> I also filed:
> 
> https://bugs.llvm.org/show_bug.cgi?id=34758 
> 
> 
> to cover the issue.
> 
> Jim
> 
> ___
> 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

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

Re: [lldb-dev] I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

[Jim Ingham via lldb-dev]

> On Sep 28, 2017, at 10:59 AM, Leonard Mosescu  wrote:
> 
> Thank you Jim! I'm at cppcon and I won't be able to work on it until Monday, 
> but I can help with a code review if you're planning to take a stab at it.

Thanks.  Not sure I'll get to this, but if I do I'll certainly put it up for 
review.

> 
> I was hoping we can avoid dealing with reentrancy but I was wrong. For 
> handling reentrancy I was briefly considering either maintaining a full blown 
> command stack or perhaps just a nesting counter.

Reentrancy into the command interpreter it is dicey at present because the 
CommandObjects weren't done quite right.  At present, the CommandObject handles 
both specifying the logic of the command and it's inputs, AND is the storage 
for the current invocation's options.  So you can only do things that might 
re-enter the interpreter after you've done all the reading of options you are 
likely to do.  That hasn't been a big problem, but is kinda gross... 

At some point, we need to add a CommandInvocation object that holds the option 
values for a given invocation.  Then we can have a stack of invocations, which 
might be a natural place to organize this sort of thing as well.

I'm not implying that you should do this work, but sometimes having a future 
direction in mind will help your thinking.

In this light, I agree with Greg that a stack would be a good way to go.  
That's a beginning to model the more correct behavior of the interpreter.

> 
> Also, with reentrancy, I think that interruption should affect the "outmost" 
> command scope rather than just interrupting the current command, what do you 
> think?
> 
> 

If somebody does "command source" of a file with a bunch of commands, one of 
which is grinding away producing output, my intuition is that they would want 
to interrupt that one for sure.  But trying to imagine using this, I think that 
for interrupting command source you would really want to roll all the way back 
out to giving the user control of the session.  So my feeling is "both".

Jim

> 
> 
> On Wed, Sep 27, 2017 at 6:46 PM, Jim Ingham via lldb-dev 
>  wrote:
> This actually asserts on any use "command source" is the one command that 
> re-enters the command interpreter.  It should be as simple as getting command 
> source to rest the state flag before it goes to do the sourcing.  I'll check 
> that out tomorrow if nobody gets to it first.
> 
> command source is one of a set of early commands that we got into lldb before 
> we had hired the person who wrote the testsuite way way back in the day, and 
> though we went and backfilled the tests at that point, apparently we missed 
> command source.  So we'll also have to add a test for that.
> 
> I also filed:
> 
> https://bugs.llvm.org/show_bug.cgi?id=34758
> 
> to cover the issue.
> 
> Jim
> 
> ___
> 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

[lldb-dev] [Bug 34771] New: Testsuite should support overriding settings

[via lldb-dev]

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

Bug ID: 34771
   Summary: Testsuite should support overriding settings
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: scalla...@apple.com
CC: llvm-b...@lists.llvm.org

The LLDB testsuite should have a flag that allows the user to provide a custom
file, similar to .lldbinit, which has settings that are set for each test.

This would make it very easy to run the testsuite with experimental settings
enabled.

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

[lldb-dev] [Bug 34772] New: Fix all remaining testsuite failures with target.experimental.use-modern-type-lookup

[via lldb-dev]

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

Bug ID: 34772
   Summary: Fix all remaining testsuite failures with
target.experimental.use-modern-type-lookup
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: scalla...@apple.com
CC: llvm-b...@lists.llvm.org

Currently target.experimental.use-modern-type-lookup is defaulted to off.

There are several reasons it should be on:

 - ExternalASTMerger is shared code which will allow other clients to complete
types from multiple sources, as LLDB does.

 - This will allow us to remove the ClangASTImporter, a large container of
state which can go bad over time.

 - ExternalASTMerger has much more complete unit testing; I believe the
remaining testsuite failures are because of as-yet-incomplete LLDB use of it.

It's possible to run the testsuite with use-modern-type-lookup enabled, by
changing g_experimental_properties in Target.cpp to make it default-on.  The
resulting testsuite failures need to be fixed and the setting should then be
enabled.

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