[Lldb-commits] [PATCH] D56126: [NativePDB] Add basic support of methods recostruction in AST

2018-12-29 Thread Aleksandr Urakov via Phabricator via lldb-commits
aleksandr.urakov marked an inline comment as done.
aleksandr.urakov added a comment.

In D56126#1342114 , @zturner wrote:

> I think it's probably best to skip this part for now and come back to it 
> later.  The only thing that will be missing is the ability to use member 
> function templates in expressions.  Of course we need this eventually, but 
> probably there is more useful stuff to work on first.


Yes, I agree. So I can continue with virtual bases support (but only since the 
middle of January), good?

> One idea for implementing this though might be to add a pre-processing step 
> of the publics stream similar to how we pre-process the TPI stream.  This 
> would also allow us to find mangled names of global functions as well 
> (currently even for global functions, we create an empty `Mangled` structure 
> when LLDB asks us for the mangled name).  One pass over the publics stream 
> should be simpler and more straightforward than a pass over every single 
> module's symbol stream.  From there we have the address, which tells us the 
> module, and then we can use the `CompilandIndexItem::FindSymbolsByVa()` to 
> find the `S_GPROC32` record, and from there find the type.  But I think this 
> is a large effort for low value, so we should maybe wait until the easier 
> stuff is done first.  I haven't looked at the rest of the patch yet, but I 
> will in a little bit.  Thanks!

Thanks for comment! I think that such preprocessing is a good idea. But is it 
guaranteed that we will have a record in the publics stream for any function?




Comment at: lit/SymbolFile/NativePDB/ast-methods.cpp:33
+// CHECK: | |-CXXMethodDecl {{.*}} overloaded_method 'int (char) 
__attribute__((thiscall))'
+// CHECK: | | `-ParmVarDecl {{.*}} 'char'
+// CHECK: | `-CXXMethodDecl {{.*}} overloaded_method 'int (char, int, ...)'

The one thing I've forgot to say about is that parameter names are in `Symbols` 
stream too. Is it ok for now to proceed without them too?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56126/new/

https://reviews.llvm.org/D56126



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


[Lldb-commits] [PATCH] D56147: [Core] Use the implementation method `GetAddressOf` in `ValueObjectConstResultChild`

2018-12-29 Thread Aleksandr Urakov via Phabricator via lldb-commits
aleksandr.urakov created this revision.
aleksandr.urakov added reviewers: zturner, JDevlieghere, clayborg, labath.
aleksandr.urakov added a project: LLDB.
Herald added a subscriber: lldb-commits.

This patch allows to retrieve an address object for `ValueObject`'s children 
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just 
uses the corresponding method of the implementation object `m_impl` to achieve 
that.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D56147

Files:
  include/lldb/Core/ValueObjectConstResultChild.h
  packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
  source/Core/ValueObjectConstResultChild.cpp


Index: source/Core/ValueObjectConstResultChild.cpp
===
--- source/Core/ValueObjectConstResultChild.cpp
+++ source/Core/ValueObjectConstResultChild.cpp
@@ -52,6 +52,11 @@
   return m_impl.AddressOf(error);
 }
 
+lldb::addr_t ValueObjectConstResultChild::GetAddressOf(
+  bool scalar_is_load_address, AddressType* address_type) {
+  return m_impl.GetAddressOf(scalar_is_load_address, address_type);
+}
+
 ValueObject *ValueObjectConstResultChild::CreateChildAtIndex(
 size_t idx, bool synthetic_array_member, int32_t synthetic_index) {
   return m_impl.CreateChildAtIndex(idx, synthetic_array_member,
Index: packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
===
--- packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
+++ packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
@@ -153,6 +153,9 @@
 val_s = target.EvaluateExpression('s')
 val_a = target.EvaluateExpression('a')
 self.assertTrue(
+val_s.GetChildMemberWithName('a').GetAddress().IsValid(),
+VALID_VARIABLE)
+self.assertTrue(
 val_s.GetChildMemberWithName('a').AddressOf(),
 VALID_VARIABLE)
 self.assertTrue(
Index: include/lldb/Core/ValueObjectConstResultChild.h
===
--- include/lldb/Core/ValueObjectConstResultChild.h
+++ include/lldb/Core/ValueObjectConstResultChild.h
@@ -63,6 +63,9 @@
 
   lldb::ValueObjectSP AddressOf(Status &error) override;
 
+  lldb::addr_t GetAddressOf(bool scalar_is_load_address = true,
+AddressType *address_type = nullptr) override;
+
   size_t GetPointeeData(DataExtractor &data, uint32_t item_idx = 0,
 uint32_t item_count = 1) override;
 


Index: source/Core/ValueObjectConstResultChild.cpp
===
--- source/Core/ValueObjectConstResultChild.cpp
+++ source/Core/ValueObjectConstResultChild.cpp
@@ -52,6 +52,11 @@
   return m_impl.AddressOf(error);
 }
 
+lldb::addr_t ValueObjectConstResultChild::GetAddressOf(
+  bool scalar_is_load_address, AddressType* address_type) {
+  return m_impl.GetAddressOf(scalar_is_load_address, address_type);
+}
+
 ValueObject *ValueObjectConstResultChild::CreateChildAtIndex(
 size_t idx, bool synthetic_array_member, int32_t synthetic_index) {
   return m_impl.CreateChildAtIndex(idx, synthetic_array_member,
Index: packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
===
--- packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
+++ packages/Python/lldbsuite/test/python_api/value/TestValueAPI.py
@@ -153,6 +153,9 @@
 val_s = target.EvaluateExpression('s')
 val_a = target.EvaluateExpression('a')
 self.assertTrue(
+val_s.GetChildMemberWithName('a').GetAddress().IsValid(),
+VALID_VARIABLE)
+self.assertTrue(
 val_s.GetChildMemberWithName('a').AddressOf(),
 VALID_VARIABLE)
 self.assertTrue(
Index: include/lldb/Core/ValueObjectConstResultChild.h
===
--- include/lldb/Core/ValueObjectConstResultChild.h
+++ include/lldb/Core/ValueObjectConstResultChild.h
@@ -63,6 +63,9 @@
 
   lldb::ValueObjectSP AddressOf(Status &error) override;
 
+  lldb::addr_t GetAddressOf(bool scalar_is_load_address = true,
+AddressType *address_type = nullptr) override;
+
   size_t GetPointeeData(DataExtractor &data, uint32_t item_idx = 0,
 uint32_t item_count = 1) override;
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D56126: [NativePDB] Add basic support of methods recostruction in AST

2018-12-29 Thread Zachary Turner via Phabricator via lldb-commits
zturner added inline comments.



Comment at: lit/SymbolFile/NativePDB/ast-methods.cpp:28
+// CHECK: |-CXXRecordDecl {{.*}} struct Struct definition
+// CHECK: | |-CXXMethodDecl {{.*}} simple_method 'void () 
__attribute__((thiscall))'
+// CHECK: | |-CXXMethodDecl {{.*}} virtual_method 'void () 
__attribute__((thiscall))' virtual

I think this is wrong.  If I compile this file myself and look at the debug 
info, the debug info says it has cdecl calling convention.  


```
D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types foo.pdb | grep -C 5 
simple_method
   0x106D | LF_METHODLIST [size = 20]
- Method [type = 0x106B, vftable offset = -1, attrs = public 
compiler-generated]
- Method [type = 0x106C, vftable offset = -1, attrs = public 
compiler-generated]
   0x106E | LF_FIELDLIST [size = 152]
- LF_VFUNCTAB type = 0x1056
- LF_ONEMETHOD [name = `simple_method`]
  type = 0x1059, vftable offset = -1, attrs = public
- LF_ONEMETHOD [name = `virtual_method`]
  type = 0x1059, vftable offset = 0, attrs = public intro virtual
- LF_ONEMETHOD [name = `static_method`]
  type = 0x105A, vftable offset = -1, attrs = public static

D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types -type-index=0x1059 
foo.pdb


 Types (TPI Stream)

  Showing 1 records.
   0x1059 | LF_MFUNCTION [size = 28]
return type = 0x0003 (void), # args = 0, param list = 0x1011
class type = 0x1057, this type = 0x1058, this adjust = 0
calling conv = cdecl, options = None
```

Also, if I use clang-cl and pass the `-ast-dump` option, it will look like this:

```
| |-CXXMethodDecl 0x23869a32c38  col:8 simple_method 'void ()'
| | `-CompoundStmt 0x23869a336f0 
```

So it doesn't have `__attribute__((thiscall))` as you do in the test.  Could 
you double check this?



Comment at: lit/SymbolFile/NativePDB/ast-methods.cpp:33
+// CHECK: | |-CXXMethodDecl {{.*}} overloaded_method 'int (char) 
__attribute__((thiscall))'
+// CHECK: | | `-ParmVarDecl {{.*}} 'char'
+// CHECK: | `-CXXMethodDecl {{.*}} overloaded_method 'int (char, int, ...)'

aleksandr.urakov wrote:
> The one thing I've forgot to say about is that parameter names are in 
> `Symbols` stream too. Is it ok for now to proceed without them too?
Parameter names should only be important once you are debugging inside of a 
function, and at that point we will have already located the `S_GPROC32` 
naturally.  So I think it's ok for us to leave the parameter names blank, and 
update the AST lazily whenever we encounter an `S_GPROC32` or `S_LPROC32` 
naturally.  We actually already parse the function parameter names in this 
method (See `PdbAstBuilder::GetOrCreateFunctionDecl`), so in fact I think 
everything will already mostly work, with only some minor code changes needed 
to support both global functions as well as member functions.



Comment at: source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp:669-672
+MemberFunctionRecord mfr;
+llvm::cantFail(
+TypeDeserializer::deserializeAs(cvt, mfr));
+return CreateFunctionType(mfr.ArgumentList, mfr.ReturnType, mfr.CallConv);

I think there is a problem here.  


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56126/new/

https://reviews.llvm.org/D56126



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


[Lldb-commits] [PATCH] D56126: [NativePDB] Add basic support of methods recostruction in AST

2018-12-29 Thread Aleksandr Urakov via Phabricator via lldb-commits
aleksandr.urakov marked an inline comment as done.
aleksandr.urakov added inline comments.



Comment at: lit/SymbolFile/NativePDB/ast-methods.cpp:28
+// CHECK: |-CXXRecordDecl {{.*}} struct Struct definition
+// CHECK: | |-CXXMethodDecl {{.*}} simple_method 'void () 
__attribute__((thiscall))'
+// CHECK: | |-CXXMethodDecl {{.*}} virtual_method 'void () 
__attribute__((thiscall))' virtual

zturner wrote:
> I think this is wrong.  If I compile this file myself and look at the debug 
> info, the debug info says it has cdecl calling convention.  
> 
> 
> ```
> D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types foo.pdb | grep -C 
> 5 simple_method
>0x106D | LF_METHODLIST [size = 20]
> - Method [type = 0x106B, vftable offset = -1, attrs = public 
> compiler-generated]
> - Method [type = 0x106C, vftable offset = -1, attrs = public 
> compiler-generated]
>0x106E | LF_FIELDLIST [size = 152]
> - LF_VFUNCTAB type = 0x1056
> - LF_ONEMETHOD [name = `simple_method`]
>   type = 0x1059, vftable offset = -1, attrs = public
> - LF_ONEMETHOD [name = `virtual_method`]
>   type = 0x1059, vftable offset = 0, attrs = public intro virtual
> - LF_ONEMETHOD [name = `static_method`]
>   type = 0x105A, vftable offset = -1, attrs = public static
> 
> D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types 
> -type-index=0x1059 foo.pdb
> 
> 
>  Types (TPI Stream)
> 
>   Showing 1 records.
>0x1059 | LF_MFUNCTION [size = 28]
> return type = 0x0003 (void), # args = 0, param list = 0x1011
> class type = 0x1057, this type = 0x1058, this adjust = 0
> calling conv = cdecl, options = None
> ```
> 
> Also, if I use clang-cl and pass the `-ast-dump` option, it will look like 
> this:
> 
> ```
> | |-CXXMethodDecl 0x23869a32c38  col:8 simple_method 'void 
> ()'
> | | `-CompoundStmt 0x23869a336f0 
> ```
> 
> So it doesn't have `__attribute__((thiscall))` as you do in the test.  Could 
> you double check this?
Hm... I tested it on x86, and I had there a "thiscall" attribute. It seems that 
on x64 it is not so. I think it's because the struct contains no fields and the 
methods doesn't use them - they don't need a "this" pointer. But I can't 
understand, why is there still "thiscall" on x86. Unfortunately, I can check it 
only two weeks later, but thanks for catching that!



Comment at: source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp:669-672
+MemberFunctionRecord mfr;
+llvm::cantFail(
+TypeDeserializer::deserializeAs(cvt, mfr));
+return CreateFunctionType(mfr.ArgumentList, mfr.ReturnType, mfr.CallConv);

zturner wrote:
> I think there is a problem here.  
I can't understand, why?..


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56126/new/

https://reviews.llvm.org/D56126



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


[Lldb-commits] [lldb] r350160 - [test] Remove flakiness decorator from TestObjCDynamicSBType

2018-12-29 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Sat Dec 29 22:10:03 2018
New Revision: 350160

URL: http://llvm.org/viewvc/llvm-project?rev=350160&view=rev
Log:
[test] Remove flakiness decorator from TestObjCDynamicSBType

The quoted bug report (llvm.org/PR20270) was closed in 2014.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py?rev=350160&r1=350159&r2=350160&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/call-function/TestCallStopAndContinue.py
 Sat Dec 29 22:10:03 2018
@@ -6,7 +6,6 @@ from __future__ import print_function
 
 
 import lldb
-from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
@@ -24,7 +23,6 @@ class ExprCommandCallStopContinueTestCas
 '// Please test these expressions while stopped at this line:')
 self.func_line = line_number('main.cpp', '{5, "five"}')
 
-@expectedFlakeyDarwin("llvm.org/pr20274")
 def test(self):
 """Test gathering result from interrupted function call."""
 self.build()


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


Re: [Lldb-commits] [PATCH] D56126: [NativePDB] Add basic support of methods recostruction in AST

2018-12-29 Thread Zachary Turner via lldb-commits
Sorry, this comment was supposed to be deleted after I realized i was wrong.

On Sat, Dec 29, 2018 at 9:12 PM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:

> aleksandr.urakov marked an inline comment as done.
> aleksandr.urakov added inline comments.
>
>
> 
> Comment at: lit/SymbolFile/NativePDB/ast-methods.cpp:28
> +// CHECK: |-CXXRecordDecl {{.*}} struct Struct definition
> +// CHECK: | |-CXXMethodDecl {{.*}} simple_method 'void ()
> __attribute__((thiscall))'
> +// CHECK: | |-CXXMethodDecl {{.*}} virtual_method 'void ()
> __attribute__((thiscall))' virtual
> 
> zturner wrote:
> > I think this is wrong.  If I compile this file myself and look at the
> debug info, the debug info says it has cdecl calling convention.
> >
> >
> > ```
> > D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types foo.pdb |
> grep -C 5 simple_method
> >0x106D | LF_METHODLIST [size = 20]
> > - Method [type = 0x106B, vftable offset = -1, attrs = public
> compiler-generated]
> > - Method [type = 0x106C, vftable offset = -1, attrs = public
> compiler-generated]
> >0x106E | LF_FIELDLIST [size = 152]
> > - LF_VFUNCTAB type = 0x1056
> > - LF_ONEMETHOD [name = `simple_method`]
> >   type = 0x1059, vftable offset = -1, attrs = public
> > - LF_ONEMETHOD [name = `virtual_method`]
> >   type = 0x1059, vftable offset = 0, attrs = public intro
> virtual
> > - LF_ONEMETHOD [name = `static_method`]
> >   type = 0x105A, vftable offset = -1, attrs = public static
> >
> > D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types
> -type-index=0x1059 foo.pdb
> >
> >
> >  Types (TPI Stream)
> > 
> >   Showing 1 records.
> >0x1059 | LF_MFUNCTION [size = 28]
> > return type = 0x0003 (void), # args = 0, param list = 0x1011
> > class type = 0x1057, this type = 0x1058, this adjust = 0
> > calling conv = cdecl, options = None
> > ```
> >
> > Also, if I use clang-cl and pass the `-ast-dump` option, it will look
> like this:
> >
> > ```
> > | |-CXXMethodDecl 0x23869a32c38  col:8 simple_method
> 'void ()'
> > | | `-CompoundStmt 0x23869a336f0 
> > ```
> >
> > So it doesn't have `__attribute__((thiscall))` as you do in the test.
> Could you double check this?
> Hm... I tested it on x86, and I had there a "thiscall" attribute. It seems
> that on x64 it is not so. I think it's because the struct contains no
> fields and the methods doesn't use them - they don't need a "this" pointer.
> But I can't understand, why is there still "thiscall" on x86.
> Unfortunately, I can check it only two weeks later, but thanks for catching
> that!

Ahh that explains it.  X64 just uses one calling convention and doesn’t
distinguish between thiscall (the compiler will even ignore the keyword).
I think we can just remove this from the test and it should be fine



>
>
> 
> Comment at: source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp:669-672
> +MemberFunctionRecord mfr;
> +llvm::cantFail(
> +TypeDeserializer::deserializeAs(cvt, mfr));
> +return CreateFunctionType(mfr.ArgumentList, mfr.ReturnType,
> mfr.CallConv);
> 
> zturner wrote:
> > I think there is a problem here.
> I can't understand, why?..
>
>
> Repository:
>   rLLDB LLDB
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D56126/new/
>
> https://reviews.llvm.org/D56126
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D56126: [NativePDB] Add basic support of methods recostruction in AST

2018-12-29 Thread Aleksandr Urakov via lldb-commits
Yes, right! There's x64 fastcall for everything. Ok, I'll remove it later,
thanks!

Am So., 30. Dez. 2018, 09:26 hat Zachary Turner 
geschrieben:

> Sorry, this comment was supposed to be deleted after I realized i was
> wrong.
>
> On Sat, Dec 29, 2018 at 9:12 PM Aleksandr Urakov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aleksandr.urakov marked an inline comment as done.
>> aleksandr.urakov added inline comments.
>>
>>
>> 
>> Comment at: lit/SymbolFile/NativePDB/ast-methods.cpp:28
>> +// CHECK: |-CXXRecordDecl {{.*}} struct Struct definition
>> +// CHECK: | |-CXXMethodDecl {{.*}} simple_method 'void ()
>> __attribute__((thiscall))'
>> +// CHECK: | |-CXXMethodDecl {{.*}} virtual_method 'void ()
>> __attribute__((thiscall))' virtual
>> 
>> zturner wrote:
>> > I think this is wrong.  If I compile this file myself and look at the
>> debug info, the debug info says it has cdecl calling convention.
>> >
>> >
>> > ```
>> > D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types foo.pdb |
>> grep -C 5 simple_method
>> >0x106D | LF_METHODLIST [size = 20]
>> > - Method [type = 0x106B, vftable offset = -1, attrs =
>> public compiler-generated]
>> > - Method [type = 0x106C, vftable offset = -1, attrs =
>> public compiler-generated]
>> >0x106E | LF_FIELDLIST [size = 152]
>> > - LF_VFUNCTAB type = 0x1056
>> > - LF_ONEMETHOD [name = `simple_method`]
>> >   type = 0x1059, vftable offset = -1, attrs = public
>> > - LF_ONEMETHOD [name = `virtual_method`]
>> >   type = 0x1059, vftable offset = 0, attrs = public intro
>> virtual
>> > - LF_ONEMETHOD [name = `static_method`]
>> >   type = 0x105A, vftable offset = -1, attrs = public static
>> >
>> > D:\src\llvmbuild\ninja-x64>bin\llvm-pdbutil.exe dump -types
>> -type-index=0x1059 foo.pdb
>> >
>> >
>> >  Types (TPI Stream)
>> > 
>> >   Showing 1 records.
>> >0x1059 | LF_MFUNCTION [size = 28]
>> > return type = 0x0003 (void), # args = 0, param list = 0x1011
>> > class type = 0x1057, this type = 0x1058, this adjust = 0
>> > calling conv = cdecl, options = None
>> > ```
>> >
>> > Also, if I use clang-cl and pass the `-ast-dump` option, it will look
>> like this:
>> >
>> > ```
>> > | |-CXXMethodDecl 0x23869a32c38  col:8 simple_method
>> 'void ()'
>> > | | `-CompoundStmt 0x23869a336f0 
>> > ```
>> >
>> > So it doesn't have `__attribute__((thiscall))` as you do in the test.
>> Could you double check this?
>> Hm... I tested it on x86, and I had there a "thiscall" attribute. It
>> seems that on x64 it is not so. I think it's because the struct contains no
>> fields and the methods doesn't use them - they don't need a "this" pointer.
>> But I can't understand, why is there still "thiscall" on x86.
>> Unfortunately, I can check it only two weeks later, but thanks for catching
>> that!
>
> Ahh that explains it.  X64 just uses one calling convention and doesn’t
> distinguish between thiscall (the compiler will even ignore the keyword).
> I think we can just remove this from the test and it should be fine
>
>
>
>>
>>
>> 
>> Comment at: source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp:669-672
>> +MemberFunctionRecord mfr;
>> +llvm::cantFail(
>> +TypeDeserializer::deserializeAs(cvt, mfr));
>> +return CreateFunctionType(mfr.ArgumentList, mfr.ReturnType,
>> mfr.CallConv);
>> 
>> zturner wrote:
>> > I think there is a problem here.
>> I can't understand, why?..
>>
>>
>> Repository:
>>   rLLDB LLDB
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D56126/new/
>>
>> https://reviews.llvm.org/D56126
>>
>>
>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits