[lldb-dev] [Bug 38520] New: no pager for help.

[via lldb-dev]

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

Bug ID: 38520
   Summary: no pager for help.
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: peeter.j...@lzlabs.com
CC: llvm-b...@lists.llvm.org

If I invoke the lldb help on a given topic, most of it flies off the screen.
Example:

(lldb) help expression

It would make sense for the lldb help to be paged like gdb (and probably to use
that pager for other long text too).

I understand that there are various workarounds, like using a terminal window
with a scrollbar (provided you don't use a multiplexer like screen, which
messes that up).  The best work around for help appears to be something like
the following from another window:

lldb -b -O 'help expression' | less

which is still somewhat clumsy, especially compared to the ease of use of gdb
help.

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

Re: [lldb-dev] stable layout bug for imported record decls.

[Gábor Márton via lldb-dev]

Hi Lang, Alexey,

I dug deeper into this and it seems like the issue happens only when a
**minimal** import is used. LLDB uses the minimal import. CrossTU
static analyzer uses the normal mode.
In normal import mode, in `ImportDeclContext` we do import all the
methods in the correct order. However, in minimal mode we early return
before importing the methods.
So by merging D44100 this particular problem will not be solved.
Still, that patch sounds very reasonable and I support that we should
reorder all imported Decls, not just fields.

One trivial solution would be to change `ImporDeclContext` to behave
the same way in both modes. This is somewhat similar to the "brute
force" method you mentioned.
I am not an LLDB expert, so I am not sure if this is acceptable, and
really don't know how many LLDB tests would it break, but this seems
the simplest solution (and preferred) to me.

The other solution if you'd like to keep the minimal behavior is the
index based solution (as you mentioned).
You should compare the order of all the imported methods (and fields)
to the order in the original class in the "From" context. And I
believe you have to do that at the end of VisitFunctionDecl. It would
not work if you did that check when the type become complete, since in
minimal mode we never set the class to be incomplete.

I have created a unit test case, which fails in minimal mode and
succeeds in normal mode. You can change the mode in
`ASTImporterTestBase::TU::lazyInitImporter`.
If you provide a patch then could you please also add this test (or
similar) for both normal and minimal mode?
```
TEST_P(ASTImporterTestBase, OrderOfVirtualMethods) {
  auto Code =
  R"(
  class Base {
  public:
virtual void bar() {}
virtual void foo() {}
  };

  class Derived : public Base {
  public:
void foo() override {}
  };
  )";
  Decl *FromTU = getTuDecl(Code, Lang_CXX11, "input0.cc");
  auto *DerivedFoo = FirstDeclMatcher().match(
  FromTU, functionDecl(hasName("foo"),
   hasParent(cxxRecordDecl(hasName("Derived");
  auto *BaseBar = FirstDeclMatcher().match(
  FromTU, functionDecl(hasName("bar"),
   hasParent(cxxRecordDecl(hasName("Base");

  Import(DerivedFoo, Lang_CXX);
  // Importing Base::bar explicitly is needed only in minimal mode,
  // in normal mode we already imported all methods of Base.
  Import(BaseBar, Lang_CXX);

  Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
  auto *ImportedBase = FirstDeclMatcher().match(
  ToTU, cxxRecordDecl(hasName("Base")));
  MatchVerifier Verifier;
  EXPECT_TRUE(Verifier.match(ImportedBase,
 cxxRecordDecl(hasMethodOrder({"bar", "foo"};
}
```

Thanks,
Gabor
On Fri, Aug 10, 2018 at 3:47 PM Alexey Sidorin  wrote:
>
> (+ Gabor and Gabor)
>
> Hi Lang,
>
> We faced a very similar issue with record fields where import order can 
> change the order of imported FieldDecls resulting in broken ASTRecordLayout. 
> The patch for this issue is on review: https://reviews.llvm.org/D44100. It 
> just reorders the fields after structure import is finished. CSA guys also 
> reported the same problem with FriendDecls in the same review.The order of 
> methods was not a problem for us but your report adds a new item to support. 
> It looks like _all_ decls inside RecordDecl have to be reordered. I'll try to 
> resurrect the patch this weekend (it is a bit outdated due to my workload, 
> sorry) and add you as a reviewer so you can check if it solves the problem or 
> not.
>
> 09.08.2018 20:46, Lang Hames via lldb-dev пишет:
>
> Hi clang-dev, lldb-dev,
>
> It looks like my clang commit r305850, which modified ASTImporter to import 
> method override tables from an external context, introduced a new bug which 
> manifests as incorrect vtable layouts for LLDB expression code.
>
> The bug itself is fairly straightforward. In r305850 I introduced the 
> following method, which is called from ASTNodeImporter::VisitFunctionDecl:
>
> void ASTNodeImporter::ImportOverrides(CXXMethodDecl *ToMethod,
>   CXXMethodDecl *FromMethod) {
>   for (auto *FromOverriddenMethod : FromMethod->overridden_methods())
> ToMethod->addOverriddenMethod(
>   cast(Importer.Import(const_cast(
> FromOverriddenMethod;
> }
>
> This will produce the correct override table, but can also cause methods in 
> the Base class to be visited in the wrong order. Consider:
>
> class Base {
> public:
>   virtual void bar() {}
>   virtual void foo() {}
> };
>
> class Derived : public Base {
> public:
>   void foo() override {}
> };
>
> If Derived is imported into a new context before Base, then the importer will 
> visit Derived::foo, and (via ImportOverrides) immediately import Base::foo, 
> but this happens before Base::bar is imported. As a consequence, the decl 
> order on the imported Base class wil

Re: [lldb-dev] Missing Value Formats for wchar_t* and char16_t*

[Ben Ruthig via lldb-dev]

Friendly ping on this?

On Fri, Jul 27, 2018 at 11:49 AM Ben Ruthig  wrote:

> Hi,
>
> The list of Var Formats supported  by
> LLDB appears to be missing ones for wchar_t* and char16_t data types.  I am
> aware that LLDB includes built in summary providers for said types, however
> the application in question uses some magic with a custom Data* to allow
> the underlying data type to be defined dynamically at run time.  Thus, LLDB
> is not able to infer that the actual data type is a wchar_t* and the
> desired summary provider is not used.
>
> I just wanted to see if there was already a way to accomplish this or if
> not, whether a patch to address this would be welcome?
>
> Is it possible to bind my own Named Summary to the same serializer used by
> the built in wchar_t* summary provider?
>
> Thanks,
> Ben
>


-- 
"Sometimes I've believed as many as six impossible things before breakfast"
- Alice in Wonderland
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

[+lldb-dev, since this affects all bots equally]

Alexander, it looks like there is a race condition in some of the LIT-based 
lldb-mi tests.

For example, exec-next.test:

  # Test lldb-mi -exec-next command.

  # Check that we have a valid target created via '%lldbmi %t'.
  # CHECK: ^done

  -break-insert main
  # CHECK: ^done,bkpt={number="1"

  -exec-run
  # CHECK: ^running
  # CHECK: *stopped,reason="breakpoint-hit"

  -exec-next --thread 0
  # Check that exec-next can process the case of invalid thread ID.
  # CHECK: ^error,msg="Command 'exec-next'. Thread ID invalid"

  ...

Here we are not actually waiting for the breakpoint to be hit. Synchronous mode 
ensures that the lldb-mi driver waits for each command to be completed, but 
that only means that -exec-run only returns after the process has been launched 
and does not include waiting for the program to actually hit a breakpoint. So 
if the program runs very slowly (such as often happens on a very busy bot), the 
-exec-next and subsequent commands are scheduled before the breakpoint is hit. 
In order to fix this we either need to move any tests that schedule commands 
after hitting breakpoints back to Python, or we need to add a new 
-wait-for-breakpoint MI command for testing only to force a synchronization 
point.

Could you please take look?

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

> On Aug 10, 2018, at 11:13 AM, Adrian Prantl via lldb-dev 
>  wrote:
> 
> [+lldb-dev, since this affects all bots equally]
> 
> Alexander, it looks like there is a race condition in some of the LIT-based 
> lldb-mi tests.
> 
> For example, exec-next.test:
> 
>  # Test lldb-mi -exec-next command.
> 
>  # Check that we have a valid target created via '%lldbmi %t'.
>  # CHECK: ^done
> 
>  -break-insert main
>  # CHECK: ^done,bkpt={number="1"
> 
>  -exec-run
>  # CHECK: ^running
>  # CHECK: *stopped,reason="breakpoint-hit"
> 
>  -exec-next --thread 0
>  # Check that exec-next can process the case of invalid thread ID.
>  # CHECK: ^error,msg="Command 'exec-next'. Thread ID invalid"
> 
>  ...
> 
> Here we are not actually waiting for the breakpoint to be hit. Synchronous 
> mode ensures that the lldb-mi driver waits for each command to be completed, 
> but that only means that -exec-run only returns after the process has been 
> launched and does not include waiting for the program to actually hit a 
> breakpoint. So if the program runs very slowly (such as often happens on a 
> very busy bot), the -exec-next and subsequent commands are scheduled before 
> the breakpoint is hit. In order to fix this we either need to move any tests 
> that schedule commands after hitting breakpoints back to Python, or we need 
> to add a new -wait-for-breakpoint MI command for testing only to force a 
> synchronization point.

In order to test my hypothesis, you could set the breakpoint in a different 
function than main and insert a sleep() into the program to simulate the 
condition on the bots, i.e.:

  void foo() {
// actual test code below
...
  }

  int main(int argc, char ** argv) {
sleep(10);
foo();
  }

and in the test:

  # instead of main:
  -break-insert foo
  # and then :-)
  -some-command-that-would-fail-if-executed-before-breakpoint-is-hit

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

[adding lldb-dev back to the conversation]

> On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> 
> 
> 
>> On Aug 10, 2018, at 2:25 PM, Александр Поляков  
>> wrote:
>> 
>> I didn't check this yet. lldb-mi already runs LIT test in the --synchronous 
>> mode and the tests keep failing.
>> 
> 
> Yes, that's why I said this:
> 
> 
>>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
>>> 
>>> Before we continue to discuss -wait-for-breakpoint; where you actually able 
>>> to verify my suspicion that that is what is happening on the bots? Fred 
>>> suggested to me offline today that in synchronous mode, perhaps -exec-* 
>>> should be waiting for the process to be stopped, which would also sound 
>>> like a reasonable and less invasive solution to the problem.
>>> 
>> 
> 
> Instead of adding a new command to wait for the process to be stopped we 
> might be able to just wait for the process to be stopped if in synchronous 
> mode and we are running any commands that expect a frame (such as -exec-*).
> 
> -- adrian

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Александр Поляков via lldb-dev]

AFAIK, there is no mechanism in lldb-mi to distinguish a command that
expects a frame, so we need to modify each command manually. Am I right?
If so, I found the Process::WaitForProcessToStop method which we can add to
SB API and use in lldb-mi.

сб, 11 авг. 2018 г. в 0:50, Adrian Prantl :

> [adding lldb-dev back to the conversation]
>
> > On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> >
> >
> >
> >> On Aug 10, 2018, at 2:25 PM, Александр Поляков 
> wrote:
> >>
> >> I didn't check this yet. lldb-mi already runs LIT test in the
> --synchronous mode and the tests keep failing.
> >>
> >
> > Yes, that's why I said this:
> >
> >
> >>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
> >>>
> >>> Before we continue to discuss -wait-for-breakpoint; where you actually
> able to verify my suspicion that that is what is happening on the bots?
> Fred suggested to me offline today that in synchronous mode, perhaps
> -exec-* should be waiting for the process to be stopped, which would also
> sound like a reasonable and less invasive solution to the problem.
> >>>
> >>
> >
> > Instead of adding a new command to wait for the process to be stopped we
> might be able to just wait for the process to be stopped if in synchronous
> mode and we are running any commands that expect a frame (such as -exec-*).
> >
> > -- adrian
>
>

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

I was wondering how this worked in the regular SBAPI that we use for all the 
"normal" python-based LLDB tests. The implementation of SBProcess::Continue() 
for example calls Process::Resume() or Process::ResumeSynchronous() depending 
on whether synchronous mode is set or not.
It's not immediately obvious to me whether -exec-run should wait until the 
process stopped before returning or whether -exec-step should wait until the 
process stopped before executing.

Based on a cursory reading of the sources it seems like SBTarget::Launch should 
block until the process stopped when it is in synchronous mode. Can you confirm 
this? If that is the case, can you figure out why -exec-run does not inherit 
this behavior?

-- adrian

> On Aug 10, 2018, at 4:27 PM, Александр Поляков  wrote:
> 
> AFAIK, there is no mechanism in lldb-mi to distinguish a command that expects 
> a frame, so we need to modify each command manually. Am I right?
> If so, I found the Process::WaitForProcessToStop method which we can add to 
> SB API and use in lldb-mi.
> 
> сб, 11 авг. 2018 г. в 0:50, Adrian Prantl :
> [adding lldb-dev back to the conversation]
> 
> > On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> > 
> > 
> > 
> >> On Aug 10, 2018, at 2:25 PM, Александр Поляков  
> >> wrote:
> >> 
> >> I didn't check this yet. lldb-mi already runs LIT test in the 
> >> --synchronous mode and the tests keep failing.
> >> 
> > 
> > Yes, that's why I said this:
> > 
> > 
> >>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
> >>> 
> >>> Before we continue to discuss -wait-for-breakpoint; where you actually 
> >>> able to verify my suspicion that that is what is happening on the bots? 
> >>> Fred suggested to me offline today that in synchronous mode, perhaps 
> >>> -exec-* should be waiting for the process to be stopped, which would also 
> >>> sound like a reasonable and less invasive solution to the problem.
> >>> 
> >> 
> > 
> > Instead of adding a new command to wait for the process to be stopped we 
> > might be able to just wait for the process to be stopped if in synchronous 
> > mode and we are running any commands that expect a frame (such as -exec-*).
> > 
> > -- adrian
> 
> 
> 
> -- 
> Alexander

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Александр Поляков via lldb-dev]

One important question: what do you mean talking about "block"? Does it
mean that SBTarget::Launch blocks the process and the user can't continue
working with this process until it stops?

сб, 11 авг. 2018 г. в 2:41, Adrian Prantl :

> I was wondering how this worked in the regular SBAPI that we use for all
> the "normal" python-based LLDB tests. The implementation of
> SBProcess::Continue() for example calls Process::Resume() or
> Process::ResumeSynchronous() depending on whether synchronous mode is set
> or not.
> It's not immediately obvious to me whether -exec-run should wait until the
> process stopped before returning or whether -exec-step should wait until
> the process stopped before executing.
>
> Based on a cursory reading of the sources it seems like SBTarget::Launch
> should block until the process stopped when it is in synchronous mode. Can
> you confirm this? If that is the case, can you figure out why -exec-run
> does not inherit this behavior?
>
> -- adrian
>
> > On Aug 10, 2018, at 4:27 PM, Александр Поляков 
> wrote:
> >
> > AFAIK, there is no mechanism in lldb-mi to distinguish a command that
> expects a frame, so we need to modify each command manually. Am I right?
> > If so, I found the Process::WaitForProcessToStop method which we can add
> to SB API and use in lldb-mi.
> >
> > сб, 11 авг. 2018 г. в 0:50, Adrian Prantl :
> > [adding lldb-dev back to the conversation]
> >
> > > On Aug 10, 2018, at 2:37 PM, Adrian Prantl  wrote:
> > >
> > >
> > >
> > >> On Aug 10, 2018, at 2:25 PM, Александр Поляков <
> polyakov@gmail.com> wrote:
> > >>
> > >> I didn't check this yet. lldb-mi already runs LIT test in the
> --synchronous mode and the tests keep failing.
> > >>
> > >
> > > Yes, that's why I said this:
> > >
> > >
> > >>> пт, 10 авг. 2018 г. в 23:57, Adrian Prantl :
> > >>>
> > >>> Before we continue to discuss -wait-for-breakpoint; where you
> actually able to verify my suspicion that that is what is happening on the
> bots? Fred suggested to me offline today that in synchronous mode, perhaps
> -exec-* should be waiting for the process to be stopped, which would also
> sound like a reasonable and less invasive solution to the problem.
> > >>>
> > >>
> > >
> > > Instead of adding a new command to wait for the process to be stopped
> we might be able to just wait for the process to be stopped if in
> synchronous mode and we are running any commands that expect a frame (such
> as -exec-*).
> > >
> > > -- adrian
> >
> >
> >
> > --
> > Alexander
>
>

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

> On Aug 10, 2018, at 4:50 PM, Александр Поляков  wrote:
> 
> One important question: what do you mean talking about "block"? Does it mean 
> that SBTarget::Launch blocks the process and the user can't continue working 
> with this process until it stops?

Pretty much. The same way as the interactive (lldb) command line interface 
behaves: You enter "run" and you won't get a prompt again until the process 
stops. I'm imagining (but haven't verified) that synchronous mode behaves like 
that.

-- adrian

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Александр Поляков via lldb-dev]

It seems that lldb-mi in such a situation just hangs:

build/bin/lldb-mi --synchronous bash
(gdb)
-file-exec-and-symbols "bash"
^done
(gdb)
=library-loaded,id="/bin/bash",target-name="/bin/bash",host-name="/bin/bash",symbols-loaded="0",loaded_addr="-",size="0"
-exec-run
^C^C
exit

It doesn't react to Ctrl+C and exit command.

сб, 11 авг. 2018 г. в 2:54, Adrian Prantl :

>
>
> On Aug 10, 2018, at 4:50 PM, Александр Поляков 
> wrote:
>
> One important question: what do you mean talking about "block"? Does it
> mean that SBTarget::Launch blocks the process and the user can't continue
> working with this process until it stops?
>
>
> Pretty much. The same way as the interactive (lldb) command line interface
> behaves: You enter "run" and you won't get a prompt again until the process
> stops. I'm imagining (but haven't verified) that synchronous mode behaves
> like that.
>
> -- adrian
>
>

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

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

That't interesting. Where you able to simulate the error seen on the bots by 
inserting a sleep() unto the debugged program?

-- adrian

> On Aug 10, 2018, at 5:06 PM, Александр Поляков  wrote:
> 
> It seems that lldb-mi in such a situation just hangs:
> 
> build/bin/lldb-mi --synchronous bash
> (gdb)
> -file-exec-and-symbols "bash"
> ^done
> (gdb)
> =library-loaded,id="/bin/bash",target-name="/bin/bash",host-name="/bin/bash",symbols-loaded="0",loaded_addr="-",size="0"
> -exec-run
> ^C^C
> exit
> 
> It doesn't react to Ctrl+C and exit command.
> 
> сб, 11 авг. 2018 г. в 2:54, Adrian Prantl  >:
> 
> 
>> On Aug 10, 2018, at 4:50 PM, Александр Поляков > > wrote:
>> 
>> One important question: what do you mean talking about "block"? Does it mean 
>> that SBTarget::Launch blocks the process and the user can't continue working 
>> with this process until it stops?
> 
> Pretty much. The same way as the interactive (lldb) command line interface 
> behaves: You enter "run" and you won't get a prompt again until the process 
> stops. I'm imagining (but haven't verified) that synchronous mode behaves 
> like that.
> 
> -- adrian
> 
> 
> 
> -- 
> Alexander

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