- User Since
- Jun 4 2018, 3:35 AM (27 w, 2 d)
Fri, Dec 7
Now it looks more clear, thanks!
Thanks for the comments, I've updated the patch.
Thu, Dec 6
Thanks for the interest to the feature! I've updated the patch due to the comments.
Wed, Dec 5
The similar problem with typedefs.test is here: http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1940/steps/test/logs/stdio
It looks strange. The compiler can't open the object file. And in the next build it is ok - may be it was some server failure (e.g. full disk)?
Btw, it can be useful if there ever would be a declarative format for pretty printers in LLDB.
It seems that all the reviews this one depends on are already in. Can we proceed with it?
Tue, Dec 4
Thanks! I've updated DIA PDB tests in D55230.
Update tests due to D55230
The test was broken after this commit. It seems that on MacOS X the process of the compiled test application always contains Objective C Runtime, so the part of the test, which assumes that there is no ObjC option enabled, fails. To fix it I've skip this part for Darwin here: https://reviews.llvm.org/rLLDB348250 Please, tell me if you have any objections on this.
Abandon due to D55122.
Ok, thank you!
Mon, Dec 3
I can do it, but unfortunately not this week... I want to join the native plugin development some later, at the end of this month, after some current work.
Ping! Can you look at this, please?
Fri, Nov 30
Thu, Nov 29
Wed, Nov 28
Ping! Can you take a look, please?
Tue, Nov 27
Mon, Nov 26
Fri, Nov 23
Wed, Nov 21
Can someone to have a look as well?
Update the patch, move symtab finalization back to object files.
Tue, Nov 13
LGTM too, thanks!
Nov 12 2018
But all compiles without errors if I run this manually:
clang-cl -m32 /Z7 /c /GS- C:\Work\llvm\tools\lldb\lit\SymbolFile\PDB/Inputs/SimpleTypesTest.cpp /o C:\Work\llvm\build_x86\tools\lldb\lit\SymbolFile\PDB\Output/SimpleTypesTest.cpp.enums.obj
I also have some strange failures on Windows x86 (I run tests from x64_86 MSVC command line). If I locally revert this commit and 3 fix commits right after this one, then all seems to work. Here is the failure:
C:\Work\llvm\build_x86\bin>llvm-lit.py -v C:\Work\llvm\tools\lldb\lit\SymbolFile\PDB\enums-layout.test llvm-lit.py: C:/Work/llvm\utils\lit\lit\llvm\config.py:333: note: using C:/Work/llvm/build_x86/./bin/clang.exe: C:\Work\llvm\build_x86\bin\clang.exe llvm-lit.py: C:/Work/llvm\utils\lit\lit\llvm\config.py:333: note: using C:/Work/llvm/build_x86/./bin/clang++.exe: C:\Work\llvm\build_x86\bin\clang++.exe config.cc = C:\Work\llvm\build_x86\bin\clang.exe -- Testing: 1 tests, 1 threads -- FAIL: LLDB :: SymbolFile/PDB/enums-layout.test (1 of 1) ******************** TEST 'LLDB :: SymbolFile/PDB/enums-layout.test' FAILED ******************** Script: -- : 'RUN: at line 2'; clang-cl -m32 /Z7 /c /GS- C:\Work\llvm\tools\lldb\lit\SymbolFile\PDB/Inputs/SimpleTypesTest.cpp /o C:\Work\llvm\build_x86\tools\lldb\lit\SymbolFile\PDB\Output/SimpleTypesTest.cpp.enums.obj : 'RUN: at line 3'; link C:\Work\llvm\build_x86\tools\lldb\lit\SymbolFile\PDB\Output/SimpleTypesTest.cpp.enums.obj /DEBUG /nodefaultlib /ENTRY:main /OUT:C:\Work\llvm\build_x86\tools\lldb\lit\SymbolFile\PDB\Output/SimpleTypesTest.cpp.enums.exe : 'RUN: at line 4'; C:\Work\llvm\build_x86\bin\lldb-test.EXE symbols C:\Work\llvm\build_x86\tools\lldb\lit\SymbolFile\PDB\Output/SimpleTypesTest.cpp.enums.exe | C:\Work\llvm\build_x86\bin\FileCheck.EXE C:\Work\llvm\tools\lldb\lit\SymbolFile\PDB\enums-layout.test -- Exit Code: 1
This change looks reasonable to me for solving the problem with the current LF_NESTTYPE approach. But I'm not sure... Now we all the same need to analyze mangled names and make a decision based on this. Does the current LF_NESTTYPE approach still has advantages over the "parse-scope" approach? I'm afraid that we will have to fully analyze a mangled name in the future for scoped types, so if the LF_NESTTYPE approach doesn't have a significant advantages over the "parse-scope" approach, do we really need to support them both?
Nov 8 2018
Looks good, thank you!
Nov 6 2018
Yes, it is what actually we have done in PDBASTParser::GetDeclContextContainingSymbol. Also I think that it is worth to remember if we already have created the class / function parent before, and do not create namespaces in this case. For example: N0::N1::CClass::PrivateFunc::__l2::InnerFuncStruct. We have here the PrivateFunc function and the InnerFuncStruct structure inside it. So we do not need to create the __l2 namespace inside the PrivateFunc function (moreover, it is not possible to create a namespace inside a class / function).
Yes, sure. It happens in the following functions:
- DynamicLoaderHexagonDYLD::SetRendezvousBreakpoint through findSymbolAddress
- DynamicLoaderHexagonDYLD::RendezvousBreakpointHit through findSymbolAddress
Nov 5 2018
Ping! Is it ok to proceed with it? Does anyone have objections?
Nov 3 2018
@davide You are right, this patch was the cause of the failure, sorry for that. It seems that I've found a generic issue with this patch. Thanks again for pointing to that!
Nov 2 2018
I'm not sure, but have an assumption. Here is the first green build of the green-dragon-24: http://green.lab.llvm.org/green/job/lldb-cmake/12090/ It became green after three changes, one of them is your revert of my commit, while another is Zachary's "Fix the lit test suite". I think that it's Zachary's commit fixed the build, not the revert. Moreover, my commit is Windows specific, I can't figure out, how it can break the MacOS build... So may be we will recommit it back? If it will still fail, then we could take failure logs and revert it back again.
Thanks for catching that! Unfortunately, I have no access to MacOS, can you provide some more info about failure, please?
It's ok, I was able to fix it myself. Here is the commit: r345956
This commit breaks the Windows build.
Nov 1 2018
Ping! Can you look at this, please?
Thank you for comments! I've updated the patch.
Looks good, thanks!