[ToolChains] [NetBSD] Append -rpath for shared compiler-rt runtimes

[mgorny]

Summary

Append appropriate -rpath when using shared compiler-rt runtimes,
e.g. '-fsanitize=address -shared-libasan'. There's already a similar
logic in CommonArgs.cpp but it uses non-standard arch-suffixed
installation directory while we want our driver to work with standard
installation paths.

[krytarowski]

+ vitalybuka

Can we fix it for everybody? It's certainly not restricted to NetBSD.

[phosek]

In D57303#1373035, @krytarowski wrote:

+ vitalybuka

Can we fix it for everybody? It's certainly not restricted to NetBSD.

As a point of reference, we use shared runtimes on Fuchsia but we don't use rpath so this is not something we want for every system.

[phosek]

LGTM

[krytarowski]

In D57303#1373057, @phosek wrote:

In D57303#1373035, @krytarowski wrote:

+ vitalybuka

Can we fix it for everybody? It's certainly not restricted to NetBSD.

As a point of reference, we use shared runtimes on Fuchsia but we don't use rpath so this is not something we want for every system.

How do you resolve paths? Linker cache with registry of libraries?

[phosek]

In D57303#1373061, @krytarowski wrote:

How do you resolve paths? Linker cache with registry of libraries?

DT_NEEDED aren't treated as paths, they are used as object names (keys); dynamic linker passes those to the loader service which is responsible for resolving them and returning back the corresponding memory objects.

[krytarowski]

In D57303#1373077, @phosek wrote:

In D57303#1373061, @krytarowski wrote:

How do you resolve paths? Linker cache with registry of libraries?

DT_NEEDED aren't treated as paths, they are used as object names (keys); dynamic linker passes those to the loader service which is responsible for resolving them and returning back the corresponding memory objects.

I see, I was more thinking about UNIX-like OSes as I haven't even treated -rpath here as applicable for other OSes.

[mgorny]

Given that this path changes with every clang release, so you're effectively making a hard dependency on the clang version used to build the program, I dare say some systems may either decide not to support shared runtimes at all or use ld.so.conf or equivalent that can be dynamically changed.

[dlj]

In D57303#1373163, @mgorny wrote:

Given that this path changes with every clang release, so you're effectively making a hard dependency on the clang version used to build the program, I dare say some systems may either decide not to support shared runtimes at all or use ld.so.conf or equivalent that can be dynamically changed.

Yeah, I don't think we should be stamping an -rpath unconditionally across targets. On top of static builds and ld.so.conf, this could end up nominating the wrong one of DT_RPATH and DT_RUNPATH, which is, unfortunately, still a target-specific distinction. By my quick reading of Driver/ToolChains/Linux.cpp, I think the combination of where we pass --enable-new-dtags and where we would pass -rpath would get this wrong on some systems (which would, infuriatingly, only maybe cause problems; and if so, only at runtime).

cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp

void netbsd::Linker::ConstructJob(Compilation &C, const JobAction &JA,
   Args.AddAllArgs(CmdArgs, options::OPT_t);
   Args.AddAllArgs(CmdArgs, options::OPT_Z_Flag);
   Args.AddAllArgs(CmdArgs, options::OPT_r);
 
   bool NeedsSanitizerDeps = addSanitizerRuntimes(getToolChain(), Args, CmdArgs);
   bool NeedsXRayDeps = addXRayRuntime(ToolChain, Args, CmdArgs);
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
 
+  const SanitizerArgs &SanArgs = ToolChain.getSanitizerArgs();
+  if (SanArgs.needsSharedRt()) {
+    CmdArgs.push_back("-rpath");
+    CmdArgs.push_back(Args.MakeArgString(
+        ToolChain.getCompilerRTPath().c_str()));
+  }
+
   unsigned Major, Minor, Micro;
   ToolChain.getTriple().getOSVersion(Major, Minor, Micro);
   bool useLibgcc = true;
   if (Major >= 7 || Major == 0) {
     switch (ToolChain.getArch()) {
     case llvm::Triple::aarch64:
     case llvm::Triple::aarch64_be:
     case llvm::Triple::arm: