LLD buildbot red due to MS inline asm symbol redefinition |
||||
Issue description
FAILED: frame_editor.exe frame_editor.exe.pdb
C:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x86 False ../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo /OUT:./frame_editor.exe /PDB:./frame_editor.exe.pdb @./frame_editor.exe.rsp
<inline asm>:7:2: error: invalid symbol redefinition
L__MSASMLABEL_.0__wloop:
It looks like this bot is using LTO now. MS inline asm labels are currently generated in the frontend and they're supposed to be unique across the entire TU. Obviously this is a problem when you go to LTO things and you use the same label in two TUs.
Last green build was https://build.chromium.org/p/chromium.fyi/builders/CrWinClangLLD/builds/4771, Nov 11.
,
Nov 23 2016
The multiple wloop labels are probably coming from libyuv: https://cs.chromium.org/search/?q=wloop:&sq=package:chromium&type=cs We could do a source-level workaround of giving them unique names, but that's quite a hack. MS inline asm labels are supposed to be function-local, and Clang goes out of its way to add that "__MSASMLABEL_.0" prefix.
,
Nov 23 2016
,
Nov 23 2016
This upstream bug has some discussion about how we ended up here: https://llvm.org/bugs/show_bug.cgi?id=23715 We should be using the GCC inline as '%=' feature which translates into '{:uid}' in LLVM inline asm. This makes it so that you get a unique label in each asm blob.
,
Nov 23 2016
,
Nov 23 2016
fbarchard: nothing for you to do here, this happens only in an experimental setting (lto) on an doubly-experimental bot (clang-cl with link-lld)
,
Nov 23 2016
We don't use frame_editor in Chromium, so we could easily make it so that it's excluded from Chromium builds. Would that be the easiest way?
,
Nov 23 2016
nothing to do here except for us folks working on the toolchain :-)
,
Nov 28 2016
Clang r288059 should turn that bot green, let's wait and see if it really does.
,
Nov 29 2016
OK, that one didn't go so well:
C:\b\c\b\ClangToTWin\src\sandbox\win\src\sidestep_resolver.cc(153,3): error: unexpected token in argument list
__asm {
^
<inline asm>(16,20): note: instantiated into assembly here
jz L__MSASMLABEL_.{:uid}__call_interceptor
Let's try again with clang r288093.
,
Nov 30 2016
https://build.chromium.org/p/chromium.fyi/builders/CrWinClangLLD green \o/
,
Nov 30 2016
https://build.chromium.org/p/chromium.fyi/stats/CrWinClangLLD I guess the doubling of build time on that bot is due to it now using PGO. Hrm :-/
,
Nov 30 2016
Err, LTO, not PGO.
,
Nov 30 2016
Yes, it's not fast.. but it's successfully building "all" without falling over, so we have that going for us. MSVC's LTO builds are also slow, so I'm not too concerned about our speed right now. |
||||
►
Sign in to add a comment |
||||
Comment 1 by r...@chromium.org
, Nov 23 2016