[PATCH] D134337: [clang] [Driver] More flexible rules for loading default configs (WIP)

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

In D134337#3813779 <https://reviews.llvm.org/D134337#3813779>, @sepavloff wrote:

> First clang tries to find `x86_64-pc-linux-gnu-clang.cfg`. Just tool name with added suffix `cfg`. No target override, no attempt to split tool name into components. It provides possibility to have a separate configuration for any tool. The existing mechanism does not search for such file, so compatibility cannot be broken. This variant makes it possible to use configuration file even if tool name is arbitrary and does not follow usual pattern.

That's incorrect. The existing algorithm uses precisely this file if that's how clang is named:

  $ ./bin/x86_64-pc-linux-gnu-clang --version
  clang version 16.0.0 (git at github.com:llvm/llvm-project.git 17779984ca4441657071ea5abe6ef2bb32306dce)
  Target: x86_64-pc-linux-gnu
  Thread model: posix
  InstalledDir: /home/mgorny/git/llvm-project/build/./bin
  Configuration file: /tmp/clang-config/x86_64-pc-linux-gnu-clang.cfg

Also note that it performs the arch substitution on this path:

  $ ./bin/x86_64-pc-linux-gnu-clang --version -m32
  clang version 16.0.0 (git at github.com:llvm/llvm-project.git 17779984ca4441657071ea5abe6ef2bb32306dce)
  Target: i386-pc-linux-gnu
  Thread model: posix
  InstalledDir: /home/mgorny/git/llvm-project/build/./bin
  Configuration file: /tmp/clang-config/i386-pc-linux-gnu-clang.cfg

So your proposal breaks backwards compatibility.

> If `x86_64-pc-linux-gnu-clang.cfg` is found, it is loaded as configuration file and that's all. Otherwise the middle components are dropped and only target prefix and driver mode suffix are used for the search. It is similar to the search made by existing implementation, the following files that are looked for :
>
> - `i386-clang.cfg`
> - `i386.cfg`
> - `x86_64-clang.cfg`
> - `x86_64.cfg`
>
> If the file found has form `target.cfg` or none of the files was found, clang tries to load driver-mode configuration file. The files are the same as in your algorithm:
>
> - `clang++.cfg`
> - `clang.cfg`
>
> The driver-mode configuration is loaded prior to the target config, - as it may contain default settings that target config may override. In the current implementation such files are not, risk of breaking compatibility is minimal.
>
> What do you think about this variant? Does it fit your use case?

Well, my immediate use case only needs per-driver mode configuration files, so it would work — presuming we're using the real driver mode and not the executable suffix.

However, I definitely do see potential use cases for per-target configuration files — for example, providing target-specific paths instead of hardcoding them in the driver. Please note that architecture part alone is insufficient here — there are ABIs (such as n32 ABI on mips or x32 ABI on x86_64) that can only be distinguished by `-gnuabin32` or `-gnux32` suffix rather than the architecture part. This is also relevant to hardfloat/softfloat targets, and the larger part of the triple is definitely needed for cross-toolchains that may target different operating systems.

Perhaps it would be easier if you described your use case to me — I presume you have one as author of the original patch.


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

https://reviews.llvm.org/D134337