Page MenuHomePhabricator

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

Authored by mgorny on Jan 27 2019, 10:00 AM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

mgorny created this revision.Jan 27 2019, 10:00 AM

+ vitalybuka

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

+ 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 accepted this revision.Jan 27 2019, 1:36 PM

LGTM

This revision is now accepted and ready to land.Jan 27 2019, 1:36 PM

+ 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?

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.

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.

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 accepted this revision.Jan 28 2019, 5:35 PM

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).

This revision was automatically updated to reflect the committed changes.