In D100232#2680806, @zequanwu wrote:

Can you add a test case for the llvm-cov new flag? Otherwise looks good to me.

In D100535#2709646, @vsk wrote:

@phosek I apologize for the delay in reviewing this.

Thanks for doing this. I've done a few passes over the logic changes and think they look fine. I think the only thing that's missing is a .covmapping test blob to test the new v4 support.

I don't think we need this anymore.

In D45639#2705702, @ldionne wrote:

In D45639#2703913, @JDevlieghere wrote:

This breaks TestAppleSimulatorOSType.py on GreenDragon. First failed build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/
[...]

Based on your description above, shouldn't it prefer the libc++ form the sysroot?

Actually, it's the other way around. In the discussion above, we say it's the toolchain path first, then anything provided with -L, and then the sysroot. Here you have a dylib in the toolchain root (assuming that's what jenkins/workspace/lldb-cmake/lldb-build is), so it's using that. It seems that the library built in the toolchain root is built for x68_64 (probably your host), whereas you'd need it to be built for the target (i386 simulator).

In D100909#2703521, @MaskRay wrote:

Test?

Another attempt is rGcaff17e503fe.

In D45639#2702746, @thakis wrote:

Looks like this breaks tests on windows: http://45.33.8.238/win/37191/step_7.txt

LGTM

Ping?

I see, it's exposed here https://github.com/llvm/llvm-project/blob/6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619/compiler-rt/include/sanitizer/hwasan_interface.h#L88.

In D100631#2695553, @phosek wrote:

I'll check with zxtest maintainers.

I'll check with zxtest maintainers.

In D45639#2692142, @ldionne wrote:

In D45639#2383754, @smeenai wrote:

Just following up on this, cos I'm curious :) I have 12.1 now, and I still only see the C++ headers in the toolchain and not in any of the SDKs.

Look in Xcode 12.5 beta 3, you should see libc++ headers in the SDK. You'll also see headers alongside Clang, however those are not being used. They are just there for some internal reasons but eventually we'll have only one copy of the headers, and they'll be in the SDK.

As I explained in https://reviews.llvm.org/D45639#2360267, I think this is the right way forward. We want LLVM Clang to prefer the libc++.dylib (and headers) shipped in the toolchain if those are present, since that's the most consistent approach.

Just one question: with this patch, do we prefer the library in the SDK or the one in the toolchain if both are present? Can we get into trouble if we have both paths on the -L list? I'm trying to think of subtle issues like:

<toolchain>/lib/libc++.a
<sysroot>/lib/libc++.dylib

Which one would we pick here?

I ran into this issue when trying to create a test for D100232.

@ldionne friendly ping.

LGTM

@ldionne @curdeius friendly ping?

LGTM but you should wait a bit for @pcc or @eugenis to have a chance to to review this as well.

After this change, we're seeing Clang stuck in what appears to be an infinite loop when compiling the XRay runtime. The failing compiler invocation is:

/src/clang-llvm/llvm-build/fuchsia/./bin/clang++ --target=x86_64-unknown-linux-gnu -DXRAY_HAS_EXCEPTIONS=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/src/clang-llvm/llvm-project/compiler-rt/lib/xray/.. -I/src/clang-llvm/llvm-project/compiler-rt/lib/xray/../../include --target=x86_64-unknown-linux-gnu -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -no-canonical-prefixes -Wall -std=c++14 -Wno-unused-parameter -O2 -g -DNDEBUG -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -fno-rtti -MD -MT compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_x86_64.cpp.o -MF compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_x86_64.cpp.o.d -o compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_x86_64.cpp.o -c /src/clang-llvm/llvm-project/compiler-rt/lib/xray/xray_x86_64.cpp

@ldionne any more thoughts on this?

LGTM (I've tested this together with D99621 locally for the Fuchsia build and everything seems to be working).

In D99621#2667774, @delcypher wrote:

In D99621#2667768, @mstorsjo wrote:

Thanks, this seems to work fine in my setups now!

When building via llvm/runtimes (which I don't use so I don't have a test setup handy), I believe that sets TARGET_TRIPLE somehow. Does that end up trying to probe the triple from the compiler in that case? I guess it'd always be correct, but if we'd avoid the whole probing in that case too, that'd be great. Maybe it already does that - or the runtimes build does thing differently somehow? (I've just tried to read llvm/runtimes/CMakeLists.txt.) Or maybe we end up in a case where these routines aren't called at all in such a build?

I might be able to try to set up such a build configuration in a couple days to try that out though...

I'm not sure. Reading that code is a little confusing...

So there are external project invocations that pass

1. LLVM_DEFAULT_TARGET_TRIPLE. That looks like it's only used in compiler-rt to help with finding GNU gold/ld. So that probably doesn't matter here.
2. TARGET_TRIPLE as an argument to the llvm_ExternalProject_Add() function

The second one is a bit confusing.

There's this code inside llvm_ExternalProject_Add

if(NOT ARG_TARGET_TRIPLE)
  set(target_triple ${LLVM_DEFAULT_TARGET_TRIPLE})
else()
  set(target_triple ${ARG_TARGET_TRIPLE})
endif()

is_msvc_triple(is_msvc_target ${target_triple})

but then target_triple doesn't get used again... which makes no sense. (@phosek @beanz is this a bug?).

LGTM (I've tested this together with D99621 locally for the Fuchsia build and everything seems to be working).

I'm worried that overriding CMAKE_INSTALL_PREFIX is going to break the runtimes build where we build compiler-rt, libcxx, libcxxabi, libunwind in a single CMake build, and compiler-rt always comes first see https://github.com/llvm/llvm-project/blob/98742e42fc50f58d3f2d3f2cdbbf540288c134b9/runtimes/CMakeLists.txt#L57.

This change is pretty large so I'm wondering if we could possibly split it into two changes, one that does the purely mechanical renaming of ELF and TBE to IFS, and second one that merges the two tools?

In D99695#2667193, @zequanwu wrote:

In D99695#2664808, @phosek wrote:

In D99695#2664701, @vsk wrote:

I think then you would somehow need multiple -compilation-dir options if e.g. you have paths with different levels of ../ nesting, e.g. ../../foo.c and ../../../../bar.c. That sounds like it could become hard to manage.

In RawCoverageFilenamesReader::readUncompressed, we do:

SmallString<256> P(CWD);
llvm::sys::path::append(P, Filename);

Can this just be turned into an absolute path?

The flag would override the compilation dir that's stored inside the profile (the 0th path entry) so there should be just one. In that code snippet, it means overriding CWD.

That makes sense.
Do we need a new flag or just use -path-equivalence like this patch?

After this change, we're also seeing a leak being reported in BoringSSL when running on Debian 9 (stretch) which appears to be a false positive, see fxbug.dev/73487 for more details.

@ldionne I have update the change description to explain the new layout.

In D99706#2665635, @vitalybuka wrote:

This probably breaks the bot https://lab.llvm.org/buildbot/#/builders/37/builds/3296

@beanz do you know if clang/runtime is still being used?

In D99695#2664701, @vsk wrote:

I think then you would somehow need multiple -compilation-dir options if e.g. you have paths with different levels of ../ nesting, e.g. ../../foo.c and ../../../../bar.c. That sounds like it could become hard to manage.

In RawCoverageFilenamesReader::readUncompressed, we do:

SmallString<256> P(CWD);
llvm::sys::path::append(P, Filename);

Can this just be turned into an absolute path?

We ran into this issue as well where the compilation directory is set to . and path starts with ../.. (we use similar setup to Chromium) so llvm-cov tries to write files outside of the coverage directory. The way to address it I was considering would be to provide a way to override compilation directory, for example llvm-cov show --compilation-dir=/path/to/source/out/default ... so if the path stored in profile is ../../a/b.c, then it'd become /path/to/source/a/b.c. This would address the issue for us but I'm not sure if it's the best possible solution. What do you think?

In D97572#2662599, @thakis wrote:

We're seeing two test failures on macOS in bootstrap builds after this: https://bugs.chromium.org/p/chromium/issues/detail?id=1194745

In D99697#2662964, @Ericson2314 wrote:

Oh there is a stray LIBCXX_INSTALL_HEADER_PREFIX in LIBCXX_INSTALL_HEADER_PREFIX that should be removed, FYI.

In D89013#2662434, @ldionne wrote:

I'm personally not so concerned with the Clang driver side of things, but primarily with adding more complexity to the libc++ build. Shouldn't we be driving things from the runtimes build and setting a different CMAKE_INSTALL_PREFIX to install stuff to the right location instead? Then you can run N builds of libc++ for N targets, each setting the appropriate install path.

In D89013#2660407, @MaskRay wrote:

Regarding

/usr/include/x86_64-unknown-linux-gnu/c++/v1
/usr/include/c++/v1

With GCC multiarch, some include search paths are preceded by machine-os-env specific suffix directories.
Note: 'vendor' is not there. So you may see .../include/x86_64-linux-gnu but there is no .../include/x86_64-{pc,unknown}-linux-gnu

/usr/local/include/x86_64-linux-gnu         # affected by sysroot, multiarch, usually nonexistent
/usr/local/include                          # affected by sysroot
/tmp/opt/gcc-debug/include
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include-fixed
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/include
/usr/include/x86_64-linux-gnu               # affected by sysroot, multiarch
/usr/include                                # affected by sysroot

On Debian x86_64, /usr/include/x86_64-linux-gnu/ exists. Adding x86_64-pc-linux-gnu (an possible value of LLVM_DEFAULT_TARGET_TRIPLE) may add more confusion.

The biggest issue with the current setup is that compiler-rt build relies on various LLVM build artifacts, like using the just built Clang but not in a very disciplined way which requires us to use various workaround like this: https://github.com/llvm/llvm-project/blob/99fd0662278470f5405b8abd79b681b96cac7856/runtimes/CMakeLists.txt#L116 (if you search for compiler-rt in that file, you'll see other issues).

@ldionne this is ready for review now that D97572 landed.

Combined into D89013.

In D99621#2659869, @delcypher wrote:

In D99621#2659844, @phosek wrote:

Do you know what we need LLVMConfig.cmake for? Could we remove that dependency altogether? It's not used by any other runtime as far as I'm aware.

I wouldn't want to remove the dependency at this stage as not enough of this new code has been tested (I only tested on macOS). However, I think this patch could used as a stepping stone towards completely removing the dependency on LLVMConfig.cmake. If we landed this and did the necessary work to make this new code path work on all the host platforms we care about then I think we could remove the dependency on LLVMConfig.cmake. I'd like to see that happen because the requirement makes testing harder and seems unnecessary.

Other runtimes like libc++, libc++abi and libunwind already assume the monorepo layout and don't rely on llvm-config. Removing the llvm-config dependency would allow further cleanups in the compiler-rt build so this is a highly desirable change. Given that, I'd actually prefer just making this the default behavior.