Extends r338385 to allow the driver to compute the sysroot when an explicit path is not provided. This allows the linker to find C runtime files and the correct include directory for header files.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
Modified test which assumed the path to C++ includes was determined without use of the sysroot path.
Nico Weber (cfe-commits)
"I'm getting this warning from the mac linker after this commit:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: warning same member name (libclangDriver.RISCV.o) in output file used for input files: obj/clang/lib/Driver/ToolChains/Arch/libclangDriver.RISCV.o and: obj/clang/lib/Driver/ToolChains/libclangDriver.RISCV.o (due to use of basename, truncation, blank padding or duplicate input files)
Could we rename the file to fix that warning?"
I've tested this, regression tests involving linking now mostly pass as crt0 can now be found, but it seems that system headers are still being pulled in causing a couple of tests to fail. In particular using limits.h is causing build failures for me.
Compiling with -v, I see for riscv32-unknown-elf-clang
#include "..." search starts here: #include <...> search starts here: /data/jenkins/workspace/riscv32-llvm-gcc-branches/install/bin/../lib/gcc/riscv32-unknown-elf/8.2.0/../../../../riscv32-unknown-elf/include /usr/local/include /data/jenkins/workspace/riscv32-llvm-gcc-branches/install/lib/clang/8.0.0/include /usr/include End of search list.
whereas for riscv32-unknown-elf-gcc:
#include "..." search starts here: #include <...> search starts here: /data/jenkins/workspace/riscv32-llvm-gcc-branches/install/lib/gcc/riscv32-unknown-elf/8.2.0/include /data/jenkins/workspace/riscv32-llvm-gcc-branches/install/lib/gcc/riscv32-unknown-elf/8.2.0/include-fixed /data/jenkins/workspace/riscv32-llvm-gcc-branches/install/lib/gcc/riscv32-unknown-elf/8.2.0/../../../../riscv32-unknown-elf/include End of search list.
Can you see why system headers are still being pulled in unless --sysroot is specified?
Fixed this issue by adding -nostdsysteminc to the Clang target options, preventing the frontend from generating additional include paths.
My tests now look better, there are a couple of failures, but this seems to be a bug in newlib, rather than with clang/this patch (the bug was masked before as we would have been pulling in system headers). So this patch looks good to me.
@asb Does this look good to you/are you able to commit this?
Thanks for the patch and sorry for the delay. Once someone else marked it accepted it moves to a separate list in Phabricator - obviously I need to check the 'waiting on authors' list better.
As I see it are two changes here:
- Calculating libcxx include paths based on specified sysroot
- Computing the sysroot when an explicit path isn't provided
Could you please add a test that covers 2) above?
Rebased and ensured that -fuse-init-array is always used (as intended in D50043), since addClangTargetOptions is overidden for this patch.
Seems to be causing a test failure for someone (per comment in rL341655), reopened it for now (fails when sysroot is set via DEFAULT_SYSROOT in CMake flags).
Thanks for reopening this @kristina.
I suggest passing --sysroot= to make sure we see the expected behaviour when the sysroot is actually empty.
Note that this would not really test the scenario where DEFAULT_SYSROOT is empty and no --sysroot appears in the command line. I'm not sure if we really want to test that case (but if we do, I think we will have to move that case into a test of its own and add a feature in lit.cfg.py that describes that clang does not have any built-in default sysroot).
Thoughts?
Seems like a fairly niche case, you can request changes to this revision but there's been no regressions otherwise, buildbots have been handling this fine.
I think this may be something that would belong in a separate diff for the test suite, not for this particular diff. You can always just submit a diff for the test suite if you think it should have that option and if it would be useful as a general thing.
Hi @kristina .
Sure, I didn't mean to do that broader change here. Apologies if it read that way.
Would it be acceptable to add an empty --sysroot= to the test? I can post the change for review in another diff.
Thanks a lot.
Yes, you can submit another diff for this specific test, just use "Update Diff" and add yours on top which should open it up for re-review or use "Commandeer Revision" (and then submit another diff since it was previously closed). Up to your judgement.
Please don't perform necromancy on already committed and closed differentials (unless the commit was reverted, of course).
Do open new differentials.