[PATCH] D135108: [WIP][llvm-driver] Fix clang -fno-integrated-cc1 when invoked from the llvm driver

[Alex Brachet via Phabricator via llvm-commits]

abrachet created this revision.
abrachet added reviewers: phosek, beanz.
Herald added a subscriber: hiraditya.
Herald added a project: All.
abrachet requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This is a WIP to explore directions to fix this problem

Problem: Clang discovers the path to it's own executable and uses this
to re-invoke itself when -fno-integrated-cc1 is set, or if there are
multiple jobs, i.e. multiple source files specified. When clang is
invoked as part of the llvm driver, it's executable is going to be the
driver executable 'llvm', not the symlink 'clang', so the invocation
will look like 'llvm -cc1 ...'. The llvm driver will try to find an tool
called '-cc1' and will fail.

I tried remedying this by changing the result of
`llvm::sys::fs::getMainExecutable`, which was done so that clang errors
would look like 'clang: error: ...' and not 'llvm: error: ...'. I didn't
anticipate (or just run the tests) the problem with -fno-integrated-cc1.

Potential solutions:

1. Use the name of argv[0] as clang's executable path (as shown here)

This is the most elegant, and requires few changes to clang. The big
downside here is that invoking clang like 'llvm clang ...' will then
do a PATH lookup for clang and find the first one in your path not the
one in the same directory as the llvm binary you invoked with. This is
a showstopper problem for this method, save that we could look
specifically in the directory of the current binary, retrieved from
`getMainExecutable`. The problem in that case is that it would require
the clang symlink exist, and in the same directory as 'llvm' for
'llvm clang ...' to work. This might be fine, in practice it's unlikely
any distribution would ship 'llvm', link in 'clang' but not ship the
'clang' symlink.

2. Change `clang::driver::{,CC1}Command` to prepend "clang" to arguments

This would change Command::InProcess to be a function instead of just a
bool so that when it is set it would add/remove the leading "clang".
This is the most robust and what I initially tried until I realized
that `-no-canonical-prefixes` (as shown in this patch) will set
the executable to argv[0]. So what ends up happening is that clang
will be reinvoked as '/path/to/clang clang -cc1'. This is pretty
annoying because there's no clean way (save for flag to Driver
and then to ConstructJob, etc) to tell `Command` which of llvm, or
clang executable it is running. I guess it could try to look at the name
llvm* vs clang*, but this doesn't feel good. Ultimately this is my
favorite direction but the `-no-canonical-prefixes` issue is pretty
annoying.

3. Make llvm-driver understand -cc1 and -cc1as to mean clang.

This is pretty hacky, though likely a very simple implementation.


https://reviews.llvm.org/D135108

Files:
  clang/test/Analysis/scan-build/lit.local.cfg
  clang/test/CMakeLists.txt
  clang/test/lit.site.cfg.py.in
  clang/tools/driver/driver.cpp
  llvm/include/llvm/Support/LLVMDriver.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/LLVMDriver.cpp
  llvm/lib/Support/Path.cpp
  llvm/lib/Support/Unix/Path.inc
  llvm/lib/Support/Windows/Path.inc
  llvm/tools/llvm-driver/llvm-driver.cpp
  llvm/utils/gn/secondary/llvm/lib/Support/BUILD.gn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D135108.464828.patch
Type: text/x-patch
Size: 7178 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221003/40d997c4/attachment.bin>