- User Since
- Dec 6 2017, 1:24 PM (76 w, 4 d)
Fri, May 24
Looks good, thanks!
The Interop.Dia2Lib.dll and the msdiaXXX.dll have to match. Try regsvr32.exe "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Packages\Debugger\msdia120.dll" (or look for msdia120.dll on your PC).
You're right, I'll reduce it. There are a few unrelated changes that could be done after. I'll have to get back to you regarding the "without this change".
Thanks, I built it, but when I try to use it to load lld.pdb, it raises a "class not registered" exception, despite the fact that I followed the README.md instructions and registered msdia120.dll. DIA registration seems to be a continuing pain point in the Windows development world. :( I'll mess around with it.
Great stuff, thanks for doing this Reid! :) Inherently, this should make things a bit faster, it will also reduce cache misses.
We use a neat tool called Crunchersharp to have a broader overview:
Thu, May 23
If using -DLLVM_TOOL_LLDB_BUILD it now displays "Using /MD as required by LLDB."
If using -DLLVM_TOOL_LLDB_BUILD -DLLVM_USE_CRT_RELEASE=MT it displays "Disabling /MT as required by LLDB."
Otherwise /MT is the new default.
Wed, May 22
Reopening with fixes for LLDB.
Could you please move the test to a more approriate location? (ie. clang/trunk/test/Driver/)
Tue, May 21
Mon, May 20
Ping! Any further comments?
Fri, May 17
Thu, May 16
Wed, May 15
Thanks Paul! PresumedLoc seems to be used only as a temporary (on the stack).
Updated again with a different solution. We can't just act on Entry.getFile().hasLineDirectives() because a directive such as #line 100 simply overrides the __LINE__, not __FILE__ (we need to retain and hash the previous __FILE__ in that case). Please see an example here in the IBM documentation.
Also we can't compare by FileID because a LineEntry simply stores a string (called filename) but the buffer for that file isn't stored in the SourceManager.
Mon, May 13
Fri, May 10
In addition to the std::mutex issue @BillyONeal mentions, it seems there's a fair amount of "friction"/spinning in concrt.
As a good example, while using WIP patch D55585, about ~15% of time is spent in concrt yielding the CPU on a 6-core PC. And the more cores you have, the worse it gets, up to ~33% of time yielding the CPU on a 36-cores PC (see below).
Thu, May 9
Tue, May 7
Ping! Any further suggestions? Thanks in advance for your time.
Mon, May 6
I've commited the patch, and quoted you as the maker. You should maybe consider asking commit rights if you're planning more changes in the future?
Sun, May 5
Do you have commit access? Should I commit this for you?
Fri, May 3
Changed to use FileCheck instead of grep
Wed, May 1
So it turns out this is a symlink issue. The file clang/trunk/test/Driver/Inputs/CUDA-symlinks/usr/bin/ptxas has been synchronized on my Windows 10 PC as a regular text file, not a symlink. It looks like TortoiseSVN doesn't implement symlinks. As WSL inherits of my file system, it will not find the symbolic link. I suppose REQUIRES: !system-windows isn't enough for cuda-detect-path.cu, and it would need something like REQUIRES: symlinks along with support in lit. @rnk
Ping! Is this good to go?
Apr 26 2019
Thanks Paul, your solution is even better. I'll apply rL333311 locally - if everything's fine, do you mind if I re-land it again?
Yes the encoding is different. By running https://gist.github.com/zed/5898423 I get:
Windows 10 cmd shell: WSL: locale(False): cp1252 locale(False): UTF-8 device(stdout): cp850 device(stdout): UTF-8 stdout.encoding: utf-8 stdout.encoding: UTF-8 device(stderr): cp850 device(stderr): UTF-8 stderr.encoding: utf-8 stderr.encoding: UTF-8 device(stdin): cp850 device(stdin): UTF-8 stdin.encoding: utf-8 stdin.encoding: UTF-8
I've checked clang/llvm/lld/lldb, this seems to be the only place where raw bytes are encoded in python.
Apr 25 2019
Just a quick heads-up - the cuda-detect-path.cu test fails on WSL/Ubuntu 18.04:
aganea@MTL-BJ842:/mnt/f/svn/buildWSL$ /usr/bin/python3.6 bin/llvm-lit -vv ../clang/test/Driver/cuda-detect-path.cu llvm-lit: /mnt/f/svn/llvm/utils/lit/lit/llvm/config.py:341: note: using clang: /mnt/f/svn/buildWSL/bin/clang -- Testing: 1 tests, single process -- FAIL: Clang :: Driver/cuda-detect-path.cu (1 of 1) ******************** TEST 'Clang :: Driver/cuda-detect-path.cu' FAILED ********************
Please let me know if other changes are needed.
I simplfied the patch by moving the PDBInputFile behavior into the existing TypeServerSource class. This makes things more elegant and keeps everything related to debug types into one place.
Apr 24 2019
Adressed some of the comments.
Apr 23 2019
Apr 19 2019
Apr 17 2019
Ping! I know Reid is OOO this week and Zachary might not be available for reviewing. @ruiu could you please take a quick look at this? Thank you in advance for your time.
Apr 15 2019
Simplified as requested.
Thanks for the fix!
Apr 11 2019
Makes sense, thank you for fixing this!
Apr 9 2019
Apr 7 2019
That is strange. As you can’t mix /Yc and /Yu on the command line, MSBuild should issue two different calls to clang-cl, one with /Yc and one /Yu /MP. Can you check with ProcMon that commands are issued in the right order?
Apr 5 2019
I'll try profiling several solution on a large unity/jumbo file and get back with some results.