User Details
- User Since
- Nov 7 2017, 12:52 AM (243 w, 2 d)
Tue, Jun 21
Thu, Jun 16
Wed, Jun 15
I don't know how this works for you. CMake gets a list of implicit link dirs from parsing the ld command that clang -v outputs when linking. When $clang/lib/x86_64-unknown-linux-gnu exists, that's part of that output. Then, CMake determines the arch it later uses when finding libraries by matching architectures in each of the implicit link dirs, and $clang/lib/x86_64-unknown-linux-gnu is the first match. From there [it uses x86_64-unknown-linux-gnu](https://github.com/Kitware/CMake/blob/master/Source/cmSearchPath.cxx#L180), and of course it doesn't find libraries in /usr/lib/x86_64-linux-gnu because it never looks there in find_library. That can even affect pkg-config, because it uses that same derived architecture to find pkgconfig directories. When $clang/lib/x86_64-unknown-linux-gnu doesn't exist, /lib/x86_64-linux-gnu is the first match, and it uses x86_64-linux-gnu as arch, and that works.
Fri, Jun 10
Do you mean it found zlib?
Thu, Jun 9
Passing -Wl,/fixed as a linker flag when building the NSIS stubs fixes the issue, FWIW.
So, looking a little bit deeper, the resource editor in NSIS doesn't handle relocations, and the .reloc section is right after the .rsrc section that the resource editor will grow... So they actually have a build rule to pass /FIXED to link.exe when building their stubs with MSVC. I suppose mingw-binutils defaults to non-relocatable .exes (because the problem doesn't appear when building with mingw-gcc/mingw-binutils), and we only end up with relocatable .exes because we're building with mingw-clang/lld and lld defaults to relocatable .exes.
I'd call this a build system bug.
The base relocation table usually resides in the .reloc section, and as the exact size (0xB68) matches, it looks like it just has got the wrong RVA in the header. With the new, more thorough checks, libObject notices that the RVA points into the .ndata section (within 0x40000 - 0x5C000) but there's only raw data covering 0x40000 - 0x40200, and 0x43000 is outside of that. Previously we'd just set up a pointer into bogus/out of range data in these cases, now we error out.
Minimal reproducer:
- git checkout 311f7839602344ca347816146edb68c0ffaaa060
- cmake llvm -B obj -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/tmp/llvm/stage1 -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi"
- ninja -C obj install
- cmake llvm -B obj2 -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang" -DCMAKE_C_COMPILER=/tmp/llvm/stage1/bin/clang
Wed, Jun 8
I don't have time to provide more details right now, but this change broke Firefox mingw builds with: llvm-strip: error: '../../dist/firefox/uninstall/helper.exe': RVA 0x43000 for base reloc table found but data is incomplete
But it is irrelevant here
What is your $HOME/Stable/bin/clang? it has to be a clang with the patch applied.
Tue, Jun 7
IOW, nothing changed since https://reviews.llvm.org/D107799#3027607
I suspect even eliminating the machine part of the target, there could still be problems with i386 vs i686.
This is causing problems finding system zlib when compiling clang with clang, because when using the target directories for runtimes, cmake determines the target name to match that, and then proceeds to try to find zlib.h in /usr/include/$target, which doesn't work when $target doesn't match the system multi-arch triple, which it doesn't on Debian systems because the runtime directory and the cmake target is e.g. x86_64-unknown-linux-gnu, and the system multiarch triple is x86_64-linux-gnu...
Apr 12 2022
Apr 11 2022
FWIW, We're seeing Firefox crashes on aarch64 macos that have been bisected to this change as well. Top frames look like:
Mar 18 2022
For some reason this change makes Firefox Linux ASAN builds break our CI in a way that doesn't even leave logs (it looks like the workers completely die)
Mar 10 2022
It turns out CMAKE_*_FLAGS is only initialized from CMAKE_*_FLAGS_INIT _after_ CMAKE_DETERMINE_COMPILER_ID is done.
It still happens when I cut down to CMAKE_TOOLCHAIN_FILE, LLVM_NATIVE_TOOLCHAIN, MSVC_BASE, WINSDK_BASE, WINSDK_VER and HOST_ARCH.
The only variables I'm passing: CMAKE_C_COMPILER_TARGET, CMAKE_CXX_COMPILER_TARGET, CMAKE_ASM_COMPILER_TARGET, CMAKE_BUILD_TYPE, LLVM_ENABLE_ASSERTIONS, LLVM_CONFIG_PATH, COMPILER_RT_DEFAULT_TARGET_ONLY, CMAKE_TOOLCHAIN_FILE, LLVM_NATIVE_TOOLCHAIN, MSVC_BASE, WINSDK_BASE, WINSDK_VER, HOST_ARCH.
Somehow this change broke cross compiling for 32-bit windows using WinMsvc.cmake. Cmake ends up adding /machine:x64 to the linker flags during one of its first checks, and that fails.
Feb 22 2022
This doesn't leave much room to use __attribute__((format(printf))) on custom printf implementations that do support %n on Android does it?
Feb 11 2022
Jan 25 2022
Dec 27 2021
@int3 Can you commit this for me?
Addressed comments and added a check that __thread_vars is aligned correctly for the test to be valuable.
Dec 24 2021
Applied clang-format.
Dec 23 2021
Dec 13 2021
FYI, I filed https://github.com/llvm/llvm-project/issues/52681 for a crash that this patch causes.
Dec 3 2021
Reduced testcase:
enum FrameIID { nsBox_id, nsIFrame_id, nsHTMLFramesetBlankFrame_id, nsHTMLFramesetBorderFrame_id, };
So far, what I've found is that in some cases, DIEnumerator::get returns the same node for similar enumerator values in different enums that happen to have the same name and value (even if their bitwidth differs), but sometimes not.
For example, in one compilation I see:
DIEnumerator::get (Name={Data@0x5575ee17ea38="nsNumberControlFrame_id", Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, BitWidth=8}, Context@0x5575e8305da0.pImpl=0x5575e8307230) = 0x55760563a708 DIEnumerator::get (Name={Data@0x5575ee17ea38="nsNumberControlFrame_id", Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, BitWidth=32}, Context@0x5575e8305da0.pImpl=0x5575e8307230) = 0x5576067e7148
In another compilation of the same file with the same flags:
DIEnumerator::get (Name={Data@0x561c659e0cc8="nsNumberControlFrame_id", Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, BitWidth=8}, Context@0x561c5fb68da0.pImpl=0x561c5fb6a230) = 0x561c7ce9dbf8 DIEnumerator::get (Name={Data@0x561c659e0cc8="nsNumberControlFrame_id", Length=23}, IsUnsigned: optimized out, Value={U={VAL=50, pVal=0x32}, BitWidth=32}, Context@0x561c5fb68da0.pImpl=0x561c5fb6a230) = 0x561c7ce9dbf8
Dec 1 2021
Nov 11 2021
Nov 10 2021
It seems to have been fixed in rG3c47c5ca13b8a502de3272e8105548715947b7a8.
Nov 4 2021
This broke determinism when building Firefox.
Nov 1 2021
The relanding in 47633af9d4a8b93f50cb711cf23489736e0226f1 broke determinism for Firefox.
Sep 22 2021
Apr 16 2021
LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR was removed in https://reviews.llvm.org/D58157, so it's unset by default.
Jan 28 2021
Firefox CI is using a custom clang, but uses a NDK otherwise (an old-ish one, clearly older than r22 which is the first that defaults to lld). And we do pass -fuse-ld=bfd at the moment for $reasons.
If clang _really_ wants to assume lld as the linker for android, then it should make using -fuse-ld=somethingelse an error and invoke ld.lld rather than ld, if it doesn't already do that.
Jan 27 2021
"Android only supports lld" might be true now, but it hasn't always been true, which means the change is not backwards compatible with versions of the NDK that don't use lld. Also, -fuse-ld is still a valid flag that can allow to use a different linker than lld.
Nov 26 2020
FWIW, when applying this patch on a LLVM10-based rustc, the rustc build fails with:
PHI node has multiple entries for the same basic block with different incoming values! %35 = phi { i64*, i32 }* [ %83, %77 ], [ %84, %77 ], [ %33, %2 ] label %77 %83 = getelementptr { i64*, i32 }, { i64*, i32 }* %35, i64 -1 %84 = getelementptr { i64*, i32 }, { i64*, i32 }* %35, i64 -1 in function _ZN80_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..SpecExtend$LT$T$C$I$GT$$GT$9from_iter17h62b0d0798a862a64E LLVM ERROR: Broken function found, compilation aborted! error: could not compile `rustc_typeck`.
Feb 7 2019
@efriedma can you take another look? Ideally, this should be backported to the release_80 branch, so that would need to be landed asap.
Feb 4 2019
Updated EmitAArch64BuiltinExpr per https://reviews.llvm.org/D57636#1383751 and the testcase per https://reviews.llvm.org/D57636#1384348
Feb 1 2019
Opened D57636
Jan 8 2019
Nov 28 2018
Nov 27 2018
Correction, the mpi_arm.c ones seem to be caught. However, warnings are also being emitted for assembly post substitution. Example:
Nov 26 2018
Assuming removing the variadicOpsAreDefs test completely (since I couldn't figure where it came from) still yields something that mostly works, it appears not to catch when the assembly writes to input operands. Examples of real code that had the problem:
Aug 28 2018
Nov 7 2017
Updated wording.