clang-cl: Expose -no-canonical-prefixes

Authored by thakis on Tue, May 29, 8:02 AM.



-no-canonical-prefixes is a weird flag: In gcc, it controls whether realpath() is called on the path of the driver binary. It's needed to support some usecases where gcc is symlinked to, see for some background.

In clang, the resource dir is found relative to the compiler binary, and without -no-canonical-prefixes that's an absolute path. For clang, the main use case for -no-canonical-prefixes is to make the -resource-dir path added by the driver relative instead of absolute. Making it relative seems like the better default, but since neither clang not gcc have -canonical-prefixes without no- which makes changing the default tricky, and since some symlink behaviors do depend on the realpath() call at least for gcc, just expose -no-canonical-prefixes in clang-cl mode.

Alternatively we could default to no-canonical-prefix-mode for clang-cl since it's less likely to be used in symlinked scenarios, but since you already need to about -no-canonical-prefixes for the non-clang-cl bits of your build, not hooking this of driver mode seems better to me.

Diff Detail

thakis created this revision.Tue, May 29, 8:02 AM

Thank you for quick supporting, but this is not sufficient for clang-cl on windows.

llvm::InitLLVM calls windows::GetCommandLineArguments, and argv0 is changed to absolute path.

Then clang's builtin include files are shown in absolute path even we specify -no-canonical-prefixes.
Can we keep using original argv0 when argv0 is not 8.3 filename? Or is there better solution?

I did test this locally before sending it out, and the -resource-dir arg passed to cc1 is relative with this patch:

$ bin/clang-cl -no-canonical-prefixes -c -###
clang version 7.0.0 
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: bin
 "bin/clang-cl" "-cc1" "-triple" "x86_64-pc-windows-msvc19.11.0" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-main-file-name" "" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" "-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" "-fms-volatile" "-fdiagnostics-format" "msvc" "-dwarf-column-info" "-debugger-tuning=gdb" "-target-linker-version" "305" "-momit-leaf-frame-pointer" "-coverage-notes-file" "/Users/thakis/src/llvm-mono/test.gcno" "-resource-dir" "lib/clang/7.0.0" "-internal-isystem" "lib/clang/7.0.0/include" "-fdeprecated-macro" "-fdebug-compilation-dir" "/Users/thakis/src/llvm-mono" "-ferror-limit" "19" "-fmessage-length" "254" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.11" "-std=c++14" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fseh-exceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "test.obj" "-x" "c++" ""

driver.cpp handles this directly here and here -- what's the problem with the InitLLVM call you point at?

thakis added a subscriber: rnk.Tue, May 29, 3:51 PM

But GetExecutablePath isn't called if -no-canonical-prefixes is passed, is
it? (See the first link I pasted above)

GetExecutablePath is called here.

You'll understand what I said if you see the behavior of clang-cl on windows.


Is this related to this change?

rnk accepted this revision.Wed, May 30, 11:32 AM



It's a test for a previous change that I made.

This revision is now accepted and ready to land.Wed, May 30, 11:32 AM
takuto.ikuta accepted this revision.Fri, Jun 1, 7:02 AM

I confirmed this CL and remove absolute path from /showIncludes when include paths are given in relative.

thakis closed this revision.Fri, Jun 1, 8:04 AM

r333761, thanks!

thakis marked 2 inline comments as done.Fri, Jun 1, 8:07 AM
thakis added inline comments.

Sorry, I missed this. It was a mistake, I removed this line again in r333762.