[RFC] Changing tool search path priority

Hi all,

I have a patch up for review that changes how external tools like gcc are found [0]. Short version, more specific names on the user’s PATH should be found before less specific names that are in the clang install dir.

This was raised in a bug report [1] and I’ll use that to describe the current behaviour.

$ clang --target=aarch64-none-elf <…>

Clang looks for a GCC to use. With one of these possible names: “aarch64-elf-none-gcc”, “gcc”, "“x86_64-unknown-linux-gnu-gcc” (which is the default triple in this example)
We look for each name in the installed dir first, so if clang is in /usr/bin we likely find /usr/bin/gcc. This isn’t going to work for cross compiling.

As in the bug, the user might expect clang to find an aarch64-elf-none-gcc on their PATH if there is one. So my change switches things so that we look for each name in the install dir (the “program path”) and then the PATH. So in this case we would search for aarch64-none-elf-gcc in the install dir and on the PATH, before falling back to look for “gcc”, and so on.

That makes sense for this situation but this code is quite generic so I wanted to check if it’s going to work for others. No existing tests were broken by my patch, but I think that’s probably just a lack of coverage on this piece of code.

A couple of things to note:

  • -B paths are not changed by my patch, they still follow the old behaviour.
  • You can work around this quite easily with -ccc-gcc-name or -B

Looking for feedback from anyone who is involved in toolchain packaging or has been in this area recently. Is this an improvement overall and will it break existing usage?

Thanks,
David Spickett.

[0] https://reviews.llvm.org/D79842
[1] https://bugs.llvm.org/show_bug.cgi?id=45693

I have a patch up for review that changes how external tools like gcc are
found [0]. Short version, more specific names on the user's PATH should be
found before less specific names that are in the clang install dir.

I don't mind inverting the flow here.

This was raised in a bug report [1] and I'll use that to describe the
current behaviour.

$ clang --target=aarch64-none-elf <...>

Clang looks for a GCC to use. With one of these possible names:
"aarch64-elf-none-gcc", "gcc", ""x86_64-unknown-linux-gnu-gcc" (which is
the default triple in this example)

...but I don't think we should ever be looking for
${DEFAULT_TRIPLE}-gcc. That doesn't make sense to me at all.

We look for each name in the installed dir first, so if clang is in
/usr/bin we likely find /usr/bin/gcc. This isn't going to work for cross
compiling.

It works with as/ld in most places, but I can understand the desire to
having them in PATH.

Joerg

…but I don’t think we should ever be looking for
${DEFAULT_TRIPLE}-gcc. That doesn’t make sense to me at all.

IIt was added in https://reviews.llvm.org/D13340. Quoting a comment there:
"“LLVMDefaultTargetTriple is the value specified with the CMake variable -DLLVM_DEFAULT_TARGET_TRIPLE= during configuration time. For example, using --target=mips64el-mti-linux will search for files prefixed with either mips64el-mti-linux-{as,ld} and mips-mti-linux-{as,ld} in our toolchain where we specify -DLLVM_DEFAULT_TARGET_TRIPLE=mips-mti-linux.”

I guess that allows you to only package one copy of tools that can handle both targets.

That seems ..strangely specific. We certainly have cases where multiple
architecture variants are targetting a single binutils environment in
NetBSD, but those are all controlled by the appropiate flags to the
tools. The default target doesn't leak through and I don't think it ever
should. That completely defeats the goal of a universal toolchain.

Joerg

I vote for not checking ${LLVM_DEFAULT_TARGET_TRIPLE}-gcc if --target is
specified.

CCed people from ⚙ D13340 Add support for the new mips-mti-linux toolchain.

Given the lack of response (they may be using different addresses with the changes to MIPS since that time) I intend to get the current patch reviewed as is. Keeping the default triple behaviour the same. Then do a follow up change to remove the default triple behaviour, which can be reverted more easily if needed.