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

[Richard Smith via lldb-dev]

On Mon, 13 Aug 2018 at 17:08, Lang Hames via cfe-dev 
wrote:

> Hi Richard,
>
> Perhaps a better approach would be to make the "minimal" mode for the
>> ASTImporter provide an ExternalASTSource to lazily complete the AST as
>> needed (thereby avoiding violating the invariant, because you would
>> populate the lexical declarations list whenever anyone actually asks for
>> it).
>
>
> This seems worth investigating. I wonder if it might also fix another bug
> that I know of involving virtual methods with covariant return types. (You
> and I actually discussed it at one of the socials a while back, but I have
> not had time to dig into it further.)
>
> The reproducer for the bug is:
>
> class Foo {};
> class Bar : public Foo {};
>
> class Base {
> public:
>   virtual Foo* foo() { return nullptr; }
> };
>
> class Derived : public Base {
> public:
>   virtual Bar* foo() { return nullptr; }
> };
>
> int main() {
>   Derived D;
>   D.foo(); // Evaluate 'D.foo()' here, crash LLDB.
> }
>
> The issue is that since Bar's definition is not used its bases are never
> imported, and so the call to Bar::bases() crashes in CodeGen. If we
> provided an ExternalASTSource, would that be able to lazily complete the
> bases?
>

Yes, such an approach should be able to solve that problem too: when
CodeGen (or indeed anything) queries any property of the definition of Foo
/ Bar (including whether a definition exists), you'll get a callback and a
chance to provide a complete type.


> Cheers,
> Lang.
>
>
> On Mon, Aug 13, 2018 at 3:30 PM Richard Smith 
> wrote:
>
>> On Thu, 9 Aug 2018 at 10:47, Lang Hames via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>> 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 will end up being [ foo, bar ],
>>> instead of [ bar, foo ]. In LLDB expression evaluation this manifests as an
>>> incorrect vtable layout for Base, with foo occupying the first slot.
>>>
>>> I am looking for suggestions on the right way to fix this. A brute force
>>> solution might be to always have ASTNodeImporter::VisitRecordDecl visit all
>>> base classes, then all virtual methods, which would ensure they are visited
>>> in the original decl order. However I do not know whether this covers all
>>> paths by which a CXXRecordDecl might be imported, nor whether the
>>> performance of this solution would be acceptable (it seems like it would
>>> preclude a lot of laziness).
>>>
>>> Alternatively we might be able to associate an index with each imported
>>> decl and sort on that when we complete the type, but that would leave
>>> imported decls in the wrong order until the type was complete, and since I
>>> do not know all the use cases for the importer I'm concerned people may
>>> rely on the decl order before type is complete.
>>>
>>> Any insight from ASTImporter experts would be greatly appreciated. :)
>>>
>>
>> Hi Lang,
>>
>> It might be interesting to consider how this is addressed by the
>> ExternalASTSource interface. There, we have separate "import the lexical
>> contents of this AST node (including populating the lexical declarations
>> list with all members, in the right order)", "import the lookup results for
>> this name in this context (and cache them but don't add them to the list of
>> lexical members)" and "import this specific declaration member (but don't
>> add it to the list of lexical members)" queries. One could imagine doing
>> something similar for the AST importer: when you're performing a minimal
>> import but you want to import a method declaration, don't insert it into
>> the list of lexical members of the enclosing record. Instead, defer doing
>> that until a complete type 

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

[Lang Hames via lldb-dev]

Hi Richard,

Perhaps a better approach would be to make the "minimal" mode for the
> ASTImporter provide an ExternalASTSource to lazily complete the AST as
> needed (thereby avoiding violating the invariant, because you would
> populate the lexical declarations list whenever anyone actually asks for
> it).


This seems worth investigating. I wonder if it might also fix another bug
that I know of involving virtual methods with covariant return types. (You
and I actually discussed it at one of the socials a while back, but I have
not had time to dig into it further.)

The reproducer for the bug is:

class Foo {};
class Bar : public Foo {};

class Base {
public:
  virtual Foo* foo() { return nullptr; }
};

class Derived : public Base {
public:
  virtual Bar* foo() { return nullptr; }
};

int main() {
  Derived D;
  D.foo(); // Evaluate 'D.foo()' here, crash LLDB.
}

The issue is that since Bar's definition is not used its bases are never
imported, and so the call to Bar::bases() crashes in CodeGen. If we
provided an ExternalASTSource, would that be able to lazily complete the
bases?

Cheers,
Lang.


On Mon, Aug 13, 2018 at 3:30 PM Richard Smith  wrote:

> On Thu, 9 Aug 2018 at 10:47, Lang Hames via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> 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 will end up being [ foo, bar ],
>> instead of [ bar, foo ]. In LLDB expression evaluation this manifests as an
>> incorrect vtable layout for Base, with foo occupying the first slot.
>>
>> I am looking for suggestions on the right way to fix this. A brute force
>> solution might be to always have ASTNodeImporter::VisitRecordDecl visit all
>> base classes, then all virtual methods, which would ensure they are visited
>> in the original decl order. However I do not know whether this covers all
>> paths by which a CXXRecordDecl might be imported, nor whether the
>> performance of this solution would be acceptable (it seems like it would
>> preclude a lot of laziness).
>>
>> Alternatively we might be able to associate an index with each imported
>> decl and sort on that when we complete the type, but that would leave
>> imported decls in the wrong order until the type was complete, and since I
>> do not know all the use cases for the importer I'm concerned people may
>> rely on the decl order before type is complete.
>>
>> Any insight from ASTImporter experts would be greatly appreciated. :)
>>
>
> Hi Lang,
>
> It might be interesting to consider how this is addressed by the
> ExternalASTSource interface. There, we have separate "import the lexical
> contents of this AST node (including populating the lexical declarations
> list with all members, in the right order)", "import the lookup results for
> this name in this context (and cache them but don't add them to the list of
> lexical members)" and "import this specific declaration member (but don't
> add it to the list of lexical members)" queries. One could imagine doing
> something similar for the AST importer: when you're performing a minimal
> import but you want to import a method declaration, don't insert it into
> the list of lexical members of the enclosing record. Instead, defer doing
> that until a complete type is required (at that point, you'd need to import
> all the relevant members anyway, including the base classes and virtual
> functions in the right order).
>
> The above approach would violate AST invariants (you'd have a declaration
> whose lexical parent doesn't believe it lexically contains the child), but
> I don't know off-hand whether that would be problematic. Perhaps a better
> approach would be to make the "minimal" mode for the ASTImporter provide an
> 

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

[Adrian Prantl via lldb-dev]

> On Aug 13, 2018, at 4:19 PM, Александр Поляков  wrote:
> 
> Yes, I do, I'm able to pass any command to lldb-mi before the breakpoint is 
> hit. I guess that making exec-run to block the control until the process 
> stops might be the solution we are looking for.

Right. I believe that it should (in synchronous mode) behave like "run" in the 
normal lldb command interpreter and block until the process has stopped. You 
could look at differences in the implementation of -exec-run and "run" in the 
command interpreter first.

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

Yes, I do, I'm able to pass any command to lldb-mi before the breakpoint is
hit. I guess that making exec-run to block the control until the process
stops might be the solution we are looking for.

On Mon, Aug 13, 2018 at 11:18 PM Adrian Prantl  wrote:

>
>
> On Aug 13, 2018, at 11:54 AM, Александр Поляков 
> wrote:
>
> Oops, I made a mistake, I typed break-insert main. Here is the right
> output:
>
> build/bin/lldb-mi a.out
> (gdb)
> -file-exec-and-symbols "a.out"
> ^done
> (gdb)
>
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> -exec-run
> ^running
> =thread-group-started,id="i1",pid="6406"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> ld-2.23.so",loaded_addr="-",size="0"
> (gdb)
>
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (gdb)
>
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
>
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> libc-2.23.so",loaded_addr="-",size="0"
> (gdb)
>
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> libc-2.23.so",loaded_addr="-",size="0"
> -break-insert func
>
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
>
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
>
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> -exec-next
> ^error,msg="Resume timed out."
> (gdb)
> (gdb)
>
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"
>
>
> Do you get control back before the breakpoint is hit? If yes, should
> -exec-run block until the process stops (in synchronous mode)?
>
>
> (gdb)
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
>
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"
> (gdb)
>
> On Mon, Aug 13, 2018 at 9:40 PM Александр Поляков 
> wrote:
>
>> Sure, this is the log with the typed commands:
>>
>> build/bin/lldb-mi a.out
>> (gdb)
>> -file-exec-and-symbols "a.out"
>> ^done
>> (gdb)
>>
>> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
>> -exec-run
>> ^running
>> =thread-group-started,id="i1",pid="4410"
>> (gdb)
>> =thread-created,id="1",group-id="i1"
>> =thread-selected,id="1"
>> (gdb)
>> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
>> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
>> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
>> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
>> ld-2.23.so",loaded_addr="-",size="0"
>> (gdb)
>>
>> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
>> (gdb)
>>
>> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
>> (gdb)
>> *running,thread-id="all"
>> (gdb)

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

[Richard Smith via lldb-dev]

On Thu, 9 Aug 2018 at 10:47, Lang Hames via cfe-dev 
wrote:

> 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 will end up being [ foo, bar ],
> instead of [ bar, foo ]. In LLDB expression evaluation this manifests as an
> incorrect vtable layout for Base, with foo occupying the first slot.
>
> I am looking for suggestions on the right way to fix this. A brute force
> solution might be to always have ASTNodeImporter::VisitRecordDecl visit all
> base classes, then all virtual methods, which would ensure they are visited
> in the original decl order. However I do not know whether this covers all
> paths by which a CXXRecordDecl might be imported, nor whether the
> performance of this solution would be acceptable (it seems like it would
> preclude a lot of laziness).
>
> Alternatively we might be able to associate an index with each imported
> decl and sort on that when we complete the type, but that would leave
> imported decls in the wrong order until the type was complete, and since I
> do not know all the use cases for the importer I'm concerned people may
> rely on the decl order before type is complete.
>
> Any insight from ASTImporter experts would be greatly appreciated. :)
>

Hi Lang,

It might be interesting to consider how this is addressed by the
ExternalASTSource interface. There, we have separate "import the lexical
contents of this AST node (including populating the lexical declarations
list with all members, in the right order)", "import the lookup results for
this name in this context (and cache them but don't add them to the list of
lexical members)" and "import this specific declaration member (but don't
add it to the list of lexical members)" queries. One could imagine doing
something similar for the AST importer: when you're performing a minimal
import but you want to import a method declaration, don't insert it into
the list of lexical members of the enclosing record. Instead, defer doing
that until a complete type is required (at that point, you'd need to import
all the relevant members anyway, including the base classes and virtual
functions in the right order).

The above approach would violate AST invariants (you'd have a declaration
whose lexical parent doesn't believe it lexically contains the child), but
I don't know off-hand whether that would be problematic. Perhaps a better
approach would be to make the "minimal" mode for the ASTImporter provide an
ExternalASTSource to lazily complete the AST as needed (thereby avoiding
violating the invariant, because you would populate the lexical
declarations list whenever anyone actually asks for it).
___
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.

[Lang Hames via lldb-dev]

Hi Alexey, Gábor,

Thank you so much for this information. This is very helpful!

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.


Sounds good to me. I will try this, see whether anything fails, and try to
get a sense of the performance impact.

Do you know of anyone using minimal import mode other than LLDB?

Cheers,
Lang

On Sat, Aug 11, 2018 at 12:20 AM Gábor Márton 
wrote:

> I have forgot to include the matcher I used for the test:
> ```
> AST_MATCHER_P(CXXRecordDecl, hasMethodOrder, std::vector,
> Order) {
>   size_t Index = 0;
>   for (CXXMethodDecl *Method : Node.methods()) {
> if (!Method->isImplicit()) {
>   if (Method->getName() != Order[Index])
> return false;
>   ++Index;
> }
>   }
>   return Index == Order.size();
> }
> ```
>
> Gabor
> On Fri, Aug 10, 2018 at 6:42 PM Gábor Márton 
> wrote:
> >
> > 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 

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

[Adrian Prantl via lldb-dev]

> On Aug 13, 2018, at 11:54 AM, Александр Поляков  
> wrote:
> 
> Oops, I made a mistake, I typed break-insert main. Here is the right output:
> 
> build/bin/lldb-mi a.out 
> (gdb)
> -file-exec-and-symbols "a.out"
> ^done
> (gdb)
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> -exec-run
> ^running
> =thread-group-started,id="i1",pid="6406"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so
>  ",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (gdb)
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so
>  ",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so
>  ",loaded_addr="-",size="0"
> -break-insert func
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00400514",func="func",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2",times="0",original-location="func"}
> (gdb)
> -exec-next
> ^error,msg="Resume timed out."
> (gdb)
> (gdb)
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"

Do you get control back before the breakpoint is hit? If yes, should -exec-run 
block until the process stops (in synchronous mode)?


> (gdb)
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00400514",func="func",args=[],file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="2"},thread-id="1",stopped-threads="all"
> (gdb)
> 
> On Mon, Aug 13, 2018 at 9:40 PM Александр Поляков  > wrote:
> Sure, this is the log with the typed commands:
> 
> build/bin/lldb-mi a.out 
> (gdb)
> -file-exec-and-symbols "a.out"
> ^done
> (gdb)
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> -exec-run
> ^running
> =thread-group-started,id="i1",pid="4410"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so 
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so
>  ",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (gdb)
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> (gdb)
> *running,thread-id="all"
> (gdb)
> (gdb)
> 

Re: [lldb-dev] [GSoC] Re-implement lldb-mi on top of the LLDB public API

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

There are lots of them, so I don't think I can list them all. But if you
are interested in some command you need to do a few simple steps:
1) go to GDB/MI specification
 and find the
command you are interested in;
2) go to lldb-mi and try to find that command there, if you can't find it,
then it's likely not yet implemented;

It's really simple. For example, we want to check -target-download command.
To do so, we don't need to look at each lldb-mi's source file, we just open
a file related to target - MICmdCmdTarget.h - and look only there.

On Mon, Aug 13, 2018 at 10:09 PM Leonard Mosescu  wrote:

> Can you please list the missing MI commands? This would be very valuable
> to both future contributors and also to the users of the LLDB MI. Thanks!
>
> On Mon, Aug 13, 2018 at 11:28 AM, Александр Поляков <
> polyakov@gmail.com> wrote:
>
>> Thank you, Leonard,
>> I'm going to keep contributing to LLVM, so I think this is not the end!
>>
>> On Mon, Aug 13, 2018 at 8:15 PM Leonard Mosescu 
>> wrote:
>>
>>> Nice to see great progress in this area!
>>>
>>> On Sun, Aug 12, 2018 at 2:49 PM, Александр Поляков via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Hi LLVM folks,

 During this summer I was working on re-implementing of lldb-mi to
 correctly use LLDB public API. You are welcome to read my final report
 where I describe the contribution and challenges I faced with.
 Link to final report: https://apolyakov.github.io/GSoC-2018/

 --
 Alexander

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


>>>
>>
>> --
>> Alexander
>>
>
>

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

Re: [lldb-dev] [GSoC] Re-implement lldb-mi on top of the LLDB public API

[Leonard Mosescu via lldb-dev]

Can you please list the missing MI commands? This would be very valuable to
both future contributors and also to the users of the LLDB MI. Thanks!

On Mon, Aug 13, 2018 at 11:28 AM, Александр Поляков 
wrote:

> Thank you, Leonard,
> I'm going to keep contributing to LLVM, so I think this is not the end!
>
> On Mon, Aug 13, 2018 at 8:15 PM Leonard Mosescu 
> wrote:
>
>> Nice to see great progress in this area!
>>
>> On Sun, Aug 12, 2018 at 2:49 PM, Александр Поляков via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi LLVM folks,
>>>
>>> During this summer I was working on re-implementing of lldb-mi to
>>> correctly use LLDB public API. You are welcome to read my final report
>>> where I describe the contribution and challenges I faced with.
>>> Link to final report: https://apolyakov.github.io/GSoC-2018/
>>>
>>> --
>>> 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] Failing LIT-based lldb-mi tests

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

Sure, this is the log with the typed commands:

build/bin/lldb-mi a.out
(gdb)
-file-exec-and-symbols "a.out"
^done
(gdb)
=library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
-exec-run
^running
=thread-group-started,id="i1",pid="4410"
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
ld-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
(gdb)
=library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
(gdb)
*running,thread-id="all"
(gdb)
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
libc-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
libc-2.23.so",loaded_addr="-",size="0"
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040052f",func="main",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="7",times="0",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040052f",func="main",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="7",times="0",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0040052f",func="main",file="test.c",fullname="/home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/exec/inputs/test.c",line="7",times="0",original-location="main"}
(gdb)
-exec-next
^error,msg="Resume timed out."
(gdb)
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

No one of the commands isn't a blocking one, but I think that -exec-run
should be blocking.

On Mon, Aug 13, 2018 at 8:10 PM Adrian Prantl  wrote:

>
>
> > On Aug 11, 2018, at 3:58 AM, Александр Поляков 
> wrote:
> >
> > I reproduced the test you suggested and got following output:
> >
> > build/bin/lldb-mi --synchronous a.out <
> llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.test
> > (gdb)
> > -file-exec-and-symbols "a.out"
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> >
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> > ^done
> > (gdb)
> >
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> > (gdb)
> >
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> > (gdb)
> > ^done
> > (gdb)
> > ^running
> > =thread-group-started,id="i1",pid="5075"
> > (gdb)
> > =thread-created,id="1",group-id="i1"
> > =thread-selected,id="1"
> > (gdb)
> > =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so
> ",target-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",host-name="/lib/x86_64-linux-gnu/ld-2.23.so
> ",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> ld-2.23.so",loaded_addr="-",size="0"
> > (gdb)
> >
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> > (gdb)
> >
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> > (gdb)
> >
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/
> libc-2.23.so",loaded_addr="-",size="0"
> > (gdb)
> >
> 

Re: [lldb-dev] [GSoC] Re-implement lldb-mi on top of the LLDB public API

[Leonard Mosescu via lldb-dev]

Nice to see great progress in this area!

On Sun, Aug 12, 2018 at 2:49 PM, Александр Поляков via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi LLVM folks,
>
> During this summer I was working on re-implementing of lldb-mi to
> correctly use LLDB public API. You are welcome to read my final report
> where I describe the contribution and challenges I faced with.
> Link to final report: https://apolyakov.github.io/GSoC-2018/
>
> --
> 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] Failing LIT-based lldb-mi tests

[Adrian Prantl via lldb-dev]

> On Aug 11, 2018, at 3:58 AM, Александр Поляков  wrote:
> 
> I reproduced the test you suggested and got following output:
> 
> build/bin/lldb-mi --synchronous a.out < 
> llvm/tools/lldb/lit/tools/lldb-mi/exec/lldb-mi-fail.test 
> (gdb)
> -file-exec-and-symbols "a.out"
> ^done
> (gdb)
> ^done
> (gdb)
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> ^done
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> (gdb)
> =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000f",func="??",file="??",fullname="??/??",line="0",times="0",original-location="f"}
> (gdb)
> ^done
> (gdb)
> ^running
> =thread-group-started,id="i1",pid="5075"
> (gdb)
> =thread-created,id="1",group-id="i1"
> =thread-selected,id="1"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so",target-name="/lib/x86_64-linux-gnu/ld-2.23.so",host-name="/lib/x86_64-linux-gnu/ld-2.23.so",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
> (gdb)
> =library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so",loaded_addr="-",size="0"
> (gdb)
> =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so",loaded_addr="-",size="0"
> (gdb)
> =thread-exited,id="1",group-id="i1"
> =thread-group-exited,id="i1",exit-code="0"
> *stopped,reason="exited-normally"
> (gdb)
> ^done
> (gdb)
> ^done
> (gdb)
> ^error,msg="Resume timed out."
> (gdb)
> ^done
> (gdb)
> 
> As a command that needs a breakpoint to be hit I chose the -exec-next 
> --thread 1. It's the same error which is seen on the bots.

Can you help me understand the order in which events happened in that log? I 
don't see the -exec-next command in the log. If you type in the commands 
manually, does it become obvious which ones are blocking and which ones aren't 
(but should be)?

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