[Support] Resolve symlinks in getMainExecutable() on Windows

[aganea]

This makes the Windows implementation for getMainExecutable() behave the same as its Linux counterpart, in regards to symlinks. Previously, when using cmake ... -DLLVM_USE_SYMLINKS=ON, calling this function wouldn't resolve to the "real", non-symlinked path.

[llvmbot]

@llvm/pr-subscribers-platform-windows

Author: Alexandre Ganea (aganea)

Changes

This makes the Windows implementation for getMainExecutable() behave the same as its Linux counterpart, in regards to symlinks. Previously, when using cmake ... -DLLVM_USE_SYMLINKS=ON, calling this function wouldn't resolve to the "real", non-symlinked path.

---

Full diff: https://github.com/llvm/llvm-project/pull/76304.diff

1 Files Affected:

• (modified) llvm/lib/Support/Windows/Path.inc (+4-1)

diff --git a/llvm/lib/Support/Windows/Path.inc b/llvm/lib/Support/Windows/Path.inc
index 168a63bb2d969d..6b50309be94d77 100644
--- a/llvm/lib/Support/Windows/Path.inc
+++ b/llvm/lib/Support/Windows/Path.inc
@@ -154,7 +154,10 @@ std::string getMainExecutable(const char *argv0, void *MainExecAddr) {
     return "";
 
   llvm::sys::path::make_preferred(PathNameUTF8);
-  return std::string(PathNameUTF8.data());
+
+  SmallString<256> RealPath;
+  sys::fs::real_path(PathNameUTF8, RealPath);
+  return (std::string)RealPath;
 }
 
 UniqueID file_status::getUniqueID() const {

[llvmbot]

@llvm/pr-subscribers-llvm-support

Author: Alexandre Ganea (aganea)

Changes

This makes the Windows implementation for getMainExecutable() behave the same as its Linux counterpart, in regards to symlinks. Previously, when using cmake ... -DLLVM_USE_SYMLINKS=ON, calling this function wouldn't resolve to the "real", non-symlinked path.

---

Full diff: https://github.com/llvm/llvm-project/pull/76304.diff

1 Files Affected:

• (modified) llvm/lib/Support/Windows/Path.inc (+4-1)

diff --git a/llvm/lib/Support/Windows/Path.inc b/llvm/lib/Support/Windows/Path.inc
index 168a63bb2d969d..6b50309be94d77 100644
--- a/llvm/lib/Support/Windows/Path.inc
+++ b/llvm/lib/Support/Windows/Path.inc
@@ -154,7 +154,10 @@ std::string getMainExecutable(const char *argv0, void *MainExecAddr) {
     return "";
 
   llvm::sys::path::make_preferred(PathNameUTF8);
-  return std::string(PathNameUTF8.data());
+
+  SmallString<256> RealPath;
+  sys::fs::real_path(PathNameUTF8, RealPath);
+  return (std::string)RealPath;
 }
 
 UniqueID file_status::getUniqueID() const {

[compnerd]

Seems reasonable at first glance. How should this behave with subst drives?

[aganea]

Seems reasonable at first glance. How should this behave with subst drives?

Since we're using GetFinalPathNameByHandleW it will always resolve to the canonical, non-subst path. My understanding is that getMainExecutable() does that on Linux as well. On Windows it wasn't the case, since mostly likely nobody uses -DLLVM_USE_SYMLINKS=ON because of the admin rights.

C:\git\llvm-project>subst Y: stage1_msvc_debug

C:\git\llvm-project>Y:

Y:\>bin\clang-cl.exe /c C:\git\a.cpp -###
clang version 18.0.0git (https://github.com/aganea/llvm-project.git 51d89243cdc1239e79a2829d2735c3ebdade0fed)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: Y:\bin
 (in-process)
 "C:\\git\\llvm-project\\stage1_msvc_debug\\bin\\llvm.exe" "clang-cl.exe" "-cc1" "-triple" "x86_64-pc-windows-msvc19.38.33133" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "a.cpp" "-mrelocation-model" (rest omitted)

[aganea]

As suggested.

[aganea]

@compnerd @MaskRay Thanks for the review!

[glandium]

This has the unfortunate consequence that if you have llvm-config in a path with spaces and call it with the short path, the paths it will emit will contain spaces, when they didn't before.

That is, before:

$ mkdir -p "FOO BAR/bin"
$ cp llvm-config.exe "FOO BAR/bin"
$ ./FOOBAR~1/llvm-config.exe --bindir
(...)\FOOBAR~1\bin

But now:

$ ./FOOBAR~1/llvm-config.exe --bindir
(...)\FOO BAR\bin

It's not too much of a problem with --bindir, but with e.g. --libs, that means we now get a spaces-separated list of files separated by spaces, which doesn't quite work (which using the shortname before worked around).

[aganea]

@glandium It is a bit unfortunate but it seems the previous behavior was "by chance". Do you happen to know what happens on Linux under the same conditions? (path with spaces or symlink without spaces pointing to a path with spaces) I could send a PR to add sys::printArg() where needed, if that sounds good to you?

[glandium]

It probably has the "contains spaces" problem on Linux. I guess sys::printArg would make sense for everything llvm-config prints out, but there's no saying whether things that consume its output will actually deal with it correctly (although, obviously, they're probably not handling things correctly anyways for the case sys::printArg would print something different).

[aganea]

How did you actually found this? What was your usage of llvm-config?

[glandium]

It's not really relevant, but it's in the Firefox build system, using llvm-config --cxxflags and llvm-config --ldflags, and it wouldn't handle the quoting sys::printArg adds, but it's entirely our problem. I'm sure there are plenty of other scripts using llvm-config and not handling quoting properly (and not handling spaces properly today).

[glandium]

llvm-config output not handling spaces is actually #28117

[aganea]

@glandium Please see #97305