[PATCH] D91442: [clang][Driver] Handle risvc in Baremetal.cpp.

Hafiz Abid Qadeer via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 17 06:15:45 PST 2020


abidh added a comment.

In D91442#2399402 <https://reviews.llvm.org/D91442#2399402>, @lenary wrote:

> In D91442#2399341 <https://reviews.llvm.org/D91442#2399341>, @abidh wrote:
>
>> In D91442#2399200 <https://reviews.llvm.org/D91442#2399200>, @lenary wrote:
>>
>>> I'm worried about this change - I *think* it doesn't cover the existing behaviour of a baremetal GCC toolchain being installed into the same prefix as clang, and clang automatically picking up that baremetal gcc toolchain. What should we expect to do here? This is especially an issue if you're trying to make a relocatable toolchain tarball, where specifying `--gcc-toolchain` automatically is difficult.
>>
>> Would it be possible to use a relative path with --gcc-toolchain then this can be checked in either RISCVToolChain.cpp or GNU.cpp and adjusted accordingly?
>
> The GCC toolchain, when given a relative path, already interprets it relative to the working directory the compiler was invoked from, not the directory the compiler is located in, iirc.

I dont think path is made absolute relative using working directory. What is happening is that if (!VFS.exists(Prefix)) call in the following line will succeed if the path existed relative to working directory. This seems accidental to me.

https://github.com/llvm/llvm-project/blob/5a9f3867046c4e1c97760e22a505f4d1d788417e/clang/lib/Driver/ToolChains/Gnu.cpp#L1947

I tried a small change to turn a relative --gcc-toolchain into absolute using the compiler installed path and it works ok.  If this is something that works for you then I can post a patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91442/new/

https://reviews.llvm.org/D91442



More information about the cfe-commits mailing list