This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Add support for computing sysroot for riscv32-unknown-elf
ClosedPublic

Authored by lewis-revill on Aug 3 2018, 5:27 AM.

Details

Summary

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.

Diff Detail

Repository
rC Clang

Event Timeline

lewis-revill created this revision.Aug 3 2018, 5:27 AM

Modified test which assumed the path to C++ includes was determined without use of the sysroot path.

xbolva00 added a subscriber: xbolva00.EditedAug 3 2018, 6:31 AM

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?"

@xbolva00 In my opinion this is an issue for another revision. Personally I would choose to rename/move the other RISCV driver file to something along the lines of RISCVLinux, however I think it is best for @asb to decide since he is the code owner for the RISC-V backend.

simoncook requested changes to this revision.Aug 14 2018, 2:47 AM

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?

This revision now requires changes to proceed.Aug 14 2018, 2:47 AM

Fixed this issue by adding -nostdsysteminc to the Clang target options, preventing the frontend from generating additional include paths.

simoncook accepted this revision.Aug 15 2018, 2:18 AM

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?

This revision is now accepted and ready to land.Aug 15 2018, 2:18 AM
asb added a comment.Aug 23 2018, 6:09 AM

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:

  1. Calculating libcxx include paths based on specified sysroot
  2. Computing the sysroot when an explicit path isn't provided

Could you please add a test that covers 2) above?

Added tests for the case where --sysroot is not provided.

asb accepted this revision.Aug 30 2018, 6:16 AM

Looks good to me, thanks!

Rebased and ensured that -fuse-init-array is always used (as intended in D50043), since addClangTargetOptions is overidden for this patch.

@asb can we get this committed?

Going to land it as it's approved by code owner.

kristina reopened this revision.EditedSep 10 2018, 9:07 AM

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).

This revision is now accepted and ready to land.Sep 10 2018, 9:07 AM

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?

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.

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.

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.

kristina closed this revision.Sep 10 2018, 11:12 AM

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.

Fair enough, sorry I suggested that.