[RFC] Changing tool search path priority

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Changing tool search path priority

Fangrui Song via cfe-dev
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.


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Changing tool search path priority

Fangrui Song via cfe-dev
On Thu, May 14, 2020 at 09:38:43AM +0100, David Spickett via cfe-dev wrote:
> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Changing tool search path priority

Fangrui Song via cfe-dev
> ...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.

On Thu, 14 May 2020 at 14:34, Joerg Sonnenberger via cfe-dev <[hidden email]> wrote:
On Thu, May 14, 2020 at 09:38:43AM +0100, David Spickett via cfe-dev wrote:
> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Changing tool search path priority

Fangrui Song via cfe-dev
On Thu, May 14, 2020 at 03:11:23PM +0100, David Spickett wrote:

> > ...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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Changing tool search path priority

Fangrui Song via cfe-dev
On 2020-05-14, Joerg Sonnenberger via cfe-dev wrote:

>On Thu, May 14, 2020 at 03:11:23PM +0100, David Spickett wrote:
>> > ...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 https://reviews.llvm.org/D13340
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev