Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[clang] recognize hexagon-*-ld.lld variants #117338

Merged
merged 1 commit into from
Nov 29, 2024

Conversation

androm3da
Copy link
Member

If we create a cross toolchain with a ${triple}-ld.lld symlink, clang finds that symlink and when it uses it, it's not recognized as "lld". Let's resolve that symlink and consider it when determining lld-ness.

For example, clang provides hexagon-link specific link arguments such as -mcpu=hexagonv65 and -march=hexagon when hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the following error:

hexagon-unknown-linux-musl-ld.lld: error: unknown emulation: cpu=hexagonv65

@androm3da androm3da requested review from nico and MaskRay November 22, 2024 15:20
@androm3da androm3da self-assigned this Nov 22, 2024
@llvmbot llvmbot added clang Clang issues not falling into any other category backend:Hexagon clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels Nov 22, 2024
@llvmbot
Copy link
Member

llvmbot commented Nov 22, 2024

@llvm/pr-subscribers-libunwind
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-backend-hexagon

Author: Brian Cain (androm3da)

Changes

If we create a cross toolchain with a ${triple}-ld.lld symlink, clang finds that symlink and when it uses it, it's not recognized as "lld". Let's resolve that symlink and consider it when determining lld-ness.

For example, clang provides hexagon-link specific link arguments such as -mcpu=hexagonv65 and -march=hexagon when hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the following error:

hexagon-unknown-linux-musl-ld.lld: error: unknown emulation: cpu=hexagonv65

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

2 Files Affected:

  • (modified) clang/lib/Driver/ToolChain.cpp (+9-3)
  • (modified) clang/lib/Driver/ToolChains/Hexagon.cpp (+5-3)
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 0d426a467e9a3b..4bf87a9f16d9d3 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -964,7 +964,7 @@ std::string ToolChain::GetLinkerPath(bool *LinkerIsLLD) const {
   StringRef UseLinker = A ? A->getValue() : CLANG_DEFAULT_LINKER;
 
   // --ld-path= takes precedence over -fuse-ld= and specifies the executable
-  // name. -B, COMPILER_PATH and PATH and consulted if the value does not
+  // name. -B, COMPILER_PATH and PATH are consulted if the value does not
   // contain a path component separator.
   // -fuse-ld=lld can be used with --ld-path= to inform clang that the binary
   // that --ld-path= points to is lld.
@@ -974,8 +974,11 @@ std::string ToolChain::GetLinkerPath(bool *LinkerIsLLD) const {
       if (llvm::sys::path::parent_path(Path).empty())
         Path = GetProgramPath(A->getValue());
       if (llvm::sys::fs::can_execute(Path)) {
+        SmallString<256> RealPath;
+        if (llvm::sys::fs::real_path(Path, RealPath))
+          RealPath = llvm::sys::path::stem(RealPath);
         if (LinkerIsLLD)
-          *LinkerIsLLD = UseLinker == "lld";
+          *LinkerIsLLD = UseLinker == "lld" || RealPath == "lld";
         return std::string(Path);
       }
     }
@@ -1014,8 +1017,11 @@ std::string ToolChain::GetLinkerPath(bool *LinkerIsLLD) const {
 
     std::string LinkerPath(GetProgramPath(LinkerName.c_str()));
     if (llvm::sys::fs::can_execute(LinkerPath)) {
+      SmallString<256> RealPath;
+      if (llvm::sys::fs::real_path(LinkerPath, RealPath))
+        RealPath = llvm::sys::path::stem(RealPath);
       if (LinkerIsLLD)
-        *LinkerIsLLD = UseLinker == "lld";
+        *LinkerIsLLD = UseLinker == "lld" || RealPath == "lld";
       return LinkerPath;
     }
   }
diff --git a/clang/lib/Driver/ToolChains/Hexagon.cpp b/clang/lib/Driver/ToolChains/Hexagon.cpp
index 29781399cbab44..625979d56730bd 100644
--- a/clang/lib/Driver/ToolChains/Hexagon.cpp
+++ b/clang/lib/Driver/ToolChains/Hexagon.cpp
@@ -294,9 +294,11 @@ constructHexagonLinkArgs(Compilation &C, const JobAction &JA,
   bool IncStartFiles = !Args.hasArg(options::OPT_nostartfiles);
   bool IncDefLibs = !Args.hasArg(options::OPT_nodefaultlibs);
   bool UseG0 = false;
-  const char *Exec = Args.MakeArgString(HTC.GetLinkerPath());
-  bool UseLLD = (llvm::sys::path::filename(Exec).equals_insensitive("ld.lld") ||
-                 llvm::sys::path::stem(Exec).equals_insensitive("ld.lld"));
+  bool UseLLD = false;
+  const char *Exec = Args.MakeArgString(HTC.GetLinkerPath(&UseLLD));
+  UseLLD = UseLLD ||
+           llvm::sys::path::filename(Exec).equals_insensitive("ld.lld") ||
+           llvm::sys::path::stem(Exec).equals_insensitive("ld.lld");
   bool UseShared = IsShared && !IsStatic;
   StringRef CpuVer = toolchains::HexagonToolChain::GetTargetCPUVersion(Args);
 

@androm3da
Copy link
Member Author

Can I create a symlink in a lit test (and presumably remove it after the test is done?).

I couldn't think of an effective way to test this, so if reviewers have suggestions, it's much appreciated.

@@ -974,8 +974,11 @@ std::string ToolChain::GetLinkerPath(bool *LinkerIsLLD) const {
if (llvm::sys::path::parent_path(Path).empty())
Path = GetProgramPath(A->getValue());
if (llvm::sys::fs::can_execute(Path)) {
SmallString<1024> RealPath;
if (llvm::sys::fs::real_path(Path, RealPath))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not make an extra syscall when UseLinker == "lld"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@androm3da androm3da requested review from a team as code owners November 22, 2024 23:25
@llvmbot llvmbot added cmake Build system in general and CMake in particular compiler-rt libunwind labels Nov 22, 2024
@@ -0,0 +1,80 @@
if (NOT DEFINED LLVM_PATH)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure that these cmake changes should be included in this patch. Many folks concerned with cmake changes will likely notice that this PR has these changes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ugh! sorry, this was unintentional. I'll fix it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was a careless mistake, failed to keep different development branches separate.

Fixed.

@ldionne ldionne removed the request for review from a team November 26, 2024 20:34
Copy link
Member

@MaskRay MaskRay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am still not sure about this change.

I think this common utility is only to make -fuse-ld=lld recognize LinkerIsLLD. Toolchains/Hexagon.cpp detects ld.lld and you can make the change there?

@androm3da androm3da removed cmake Build system in general and CMake in particular compiler-rt libunwind labels Nov 27, 2024
@androm3da androm3da changed the title [clang] recognize any *-ld.lld variant [clang] recognize hexagon-*-ld.lld variants Nov 27, 2024
@androm3da
Copy link
Member Author

I am still not sure about this change.

I think this common utility is only to make -fuse-ld=lld recognize LinkerIsLLD. Toolchains/Hexagon.cpp detects ld.lld and you can make the change there?

Okay - the scope is now reduced to Toolchains/Hexagon.cpp only.

If we create a cross toolchain with a ${triple}-ld.lld symlink, clang finds
that symlink and when it uses it, it's not recognized as "lld".  Let's
consider it as lld as long as it ends in "ld.lld".

For example, clang provides hexagon-link specific link arguments such as
`-mcpu=hexagonv65` and `-march=hexagon` when hexagon-unknown-linux-musl-ld.lld
is found.  lld rejects this with the following error:

    hexagon-unknown-linux-musl-ld.lld: error: unknown emulation: cpu=hexagonv65
@androm3da androm3da merged commit 2dc0de7 into llvm:main Nov 29, 2024
8 checks passed
tru pushed a commit to llvmbot/llvm-project that referenced this pull request Dec 3, 2024
If we create a cross toolchain with a ${triple}-ld.lld symlink, clang
finds that symlink and when it uses it, it's not recognized as "lld".
Let's resolve that symlink and consider it when determining lld-ness.

For example, clang provides hexagon-link specific link arguments such as
`-mcpu=hexagonv65` and `-march=hexagon` when
hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the
following error:

hexagon-unknown-linux-musl-ld.lld: error: unknown emulation:
cpu=hexagonv65

(cherry picked from commit 2dc0de7)
TIFitis pushed a commit to TIFitis/llvm-project that referenced this pull request Dec 18, 2024
If we create a cross toolchain with a ${triple}-ld.lld symlink, clang
finds that symlink and when it uses it, it's not recognized as "lld".
Let's resolve that symlink and consider it when determining lld-ness.

For example, clang provides hexagon-link specific link arguments such as
`-mcpu=hexagonv65` and `-march=hexagon` when
hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the
following error:

hexagon-unknown-linux-musl-ld.lld: error: unknown emulation:
cpu=hexagonv65
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:Hexagon clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants