[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny updated this revision to Diff 181484.
mgorny marked 7 inline comments as done.
mgorny set the repository for this revision to rLLD LLVM Linker.
mgorny added a comment.
Herald added a subscriber: fedor.sergeev.

Split target logic into D56650 , switched to 
using target to determine which paths to apply. While at it, copied the code 
from clang since it now can match exactly.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215

Files:
  ELF/Driver.cpp
  ELF/Driver.h


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -33,6 +33,7 @@
 private:
   void setTargetTriple(StringRef argv0, llvm::opt::InputArgList );
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -366,6 +366,56 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->TargetTriple.getArch()) {
+case llvm::Triple::x86:
+  Config->SearchPaths.push_back("=/usr/lib/i386");
+  break;
+case llvm::Triple::arm:
+case llvm::Triple::armeb:
+case llvm::Triple::thumb:
+case llvm::Triple::thumbeb:
+  switch (Config->TargetTriple.getEnvironment()) {
+  case llvm::Triple::EABI:
+  case llvm::Triple::GNUEABI:
+Config->SearchPaths.push_back("=/usr/lib/eabi");
+break;
+  case llvm::Triple::EABIHF:
+  case llvm::Triple::GNUEABIHF:
+Config->SearchPaths.push_back("=/usr/lib/eabihf");
+break;
+  default:
+Config->SearchPaths.push_back("=/usr/lib/oabi");
+break;
+  }
+  break;
+#if 0 // TODO
+case llvm::Triple::mips64:
+case llvm::Triple::mips64el:
+  if (tools::mips::hasMipsAbiArg(Args, "o32"))
+Config->SearchPaths.push_back("=/usr/lib/o32");
+  else if (tools::mips::hasMipsAbiArg(Args, "64"))
+Config->SearchPaths.push_back("=/usr/lib/64");
+  break;
+#endif
+case llvm::Triple::ppc:
+  Config->SearchPaths.push_back("=/usr/lib/powerpc");
+  break;
+case llvm::Triple::sparc:
+  Config->SearchPaths.push_back("=/usr/lib/sparc");
+  break;
+default:
+  break;
+}
+
+Config->SearchPaths.push_back("=/usr/lib");
+  }
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -397,6 +447,7 @@
   setTargetTriple(ArgsArr[0], Args);
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // Handle -v or -version.
   //


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -33,6 +33,7 @@
 private:
   void setTargetTriple(StringRef argv0, llvm::opt::InputArgList );
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -366,6 +366,56 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->TargetTriple.getArch()) {
+case llvm::Triple::x86:
+  Config->SearchPaths.push_back("=/usr/lib/i386");
+  break;
+case llvm::Triple::arm:
+case llvm::Triple::armeb:
+case llvm::Triple::thumb:
+case llvm::Triple::thumbeb:
+  switch (Config->TargetTriple.getEnvironment()) {
+  case llvm::Triple::EABI:
+  case llvm::Triple::GNUEABI:
+Config->SearchPaths.push_back("=/usr/lib/eabi");
+break;
+  case llvm::Triple::EABIHF:
+  case llvm::Triple::GNUEABIHF:
+Config->SearchPaths.push_back("=/usr/lib/eabihf");
+break;
+  default:
+Config->SearchPaths.push_back("=/usr/lib/oabi");
+break;
+  }
+  break;
+#if 0 // TODO
+case llvm::Triple::mips64:
+case llvm::Triple::mips64el:
+  if (tools::mips::hasMipsAbiArg(Args, "o32"))
+

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny added inline comments.



Comment at: ELF/Driver.cpp:770
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+

krytarowski wrote:
> krytarowski wrote:
> > arichardson wrote:
> > > arichardson wrote:
> > > > If I invoke an unprefixed ld.lld on NetBSD but want to target a 
> > > > different operating system, this will cause all the NetBSD defaults to 
> > > > apply to that binary and will possibly cause it to crash at runtime.
> > > > 
> > > > I think any config changes based on a triple would need to use an 
> > > > explicit --target= flag instead. As @ruiu says, LLD's behaviour should 
> > > > not change depending on the host OS/default LLVM triple. Given the same 
> > > > input files and command line options the resulting binary should be 
> > > > identical on any host.
> > > There needs to be a way to override the target triple that is not 
> > > creating prefixed a symlink to ld.lld. Otherwise I can't use NetBSD 
> > > ld.lld to build a non-NetBSD target without giving a value for every 
> > > config option that lld supports.
> > > 
> > > I think there should be a command line option to override the triple 
> > > (e.g. --triple= or --target=).
> > > Also how will the default this interact with input files that have the 
> > > OSABI field set? I feel like the options based on the target OSABI should 
> > > be used instead of the default triple.
> > OSABI field is not reliable way to detect OS/ABI. Everybody except FreeBSD 
> > sets UNIX SystemV.
> Actually there is a FreeBSD specific hack to detect emulation name, and it 
> has suffix `fbsd`.. if it is detected it sets FreeBSD OSABI.
> 
> We don't have a chance to use a similar hack for NetBSD in other 
> configuration options.
I've addressed `--target` option in D56650.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1350179 , @ruiu wrote:

> To be honest, I don't think I would lgtm a patch that changes lld's default 
> behavior depending on host/target only for NetBSD, and it seems like a 
> NetBSD's issue rather than an lld's issue. As I said, could you please make 
> an effort to pass the flags you need from the compiler driver to the linker 
> just like other systems do? That is easy to do, doesn't hurt anyone, probably 
> a good thing to do  anyway as it makes options explicit rather than implicit, 
> and solves at least most of the problems you have.


We will add proper mapping for other ELF targets and everybody will benefit 
from a standalone linker.

As mentioned previously it will be more than standalone as we need to introduce 
NetBSD specific customization into target binaries that is not easily mappable 
from linker options (unless someone wants to switch to Linux style ELF files on 
NetBSD, but it won't happen). From bigger changes we plan to change DT_NEEDED 
semantics for NetBSD and keep catching further integration issues.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Actually probably Linux MIPS used it and some proprietary OSes.. but we skip 
them for now. Only FreeBSD sets OSABI in lld and uses an emulation name 
detection hack. Once we will get merged TripleTarget detection we can switch it 
to use proper Triple check.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

Right, I'm not aware of anyone but FreeBSD really using the OSABI field. For 
FreeBSD it was a long standing hack around limitations in the ELF kernel 
loader. I'm not even sure if FreeBSD use(d) to set the OSABI field for the 
intermediate object files.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:375
+switch (Config->EMachine) {
+  case EM_386:
+Config->SearchPaths.push_back("=/usr/lib/i386");

As we have TargetTriple now, I would use it here instead of `Config->EMachine`, 
it will be easier to map knowledge from the Clang driver and handle special ABI 
cases.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1354603 , @krytarowski wrote:

> @mgorny could you check if we can get crossbuilding functional for:
>
> - to !NetBSD from NetBSD
> - from !NetBSD to NetBSD.
> - from NetBSD/amd64 to NetBSD/aarch64
>
>   I wonder whether it can work if we will keep using 'ld' file name for a 
> linker.


Actually we have discussed it internally with @mgorny and we will propose a 
patch in Clang to handle this easier/better.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@mgorny could you check if we can get crossbuilding functional for:

- to !NetBSD from NetBSD
- from !NetBSD to NetBSD.
- from NetBSD/amd64 to NetBSD/aarch64

I wonder whether it can work if we will keep using 'ld' file name for a linker.




Comment at: ELF/Driver.cpp:369
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {

From a stylistic point of view, I would introduce a dedicated file for the 
NetBSD driver (`DriverNetBSD.cpp`?) that overloads generic ` 
LinkerDriver::appendDefaultSearchPaths()`.

I have no opinion what C++ semantics to use for it.

The generic driver could be empty or use use 
`Config->SearchPaths.push_back("=/usr/lib");`. Probably empty is better as it 
would be more generic.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:770
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+

krytarowski wrote:
> arichardson wrote:
> > arichardson wrote:
> > > If I invoke an unprefixed ld.lld on NetBSD but want to target a different 
> > > operating system, this will cause all the NetBSD defaults to apply to 
> > > that binary and will possibly cause it to crash at runtime.
> > > 
> > > I think any config changes based on a triple would need to use an 
> > > explicit --target= flag instead. As @ruiu says, LLD's behaviour should 
> > > not change depending on the host OS/default LLVM triple. Given the same 
> > > input files and command line options the resulting binary should be 
> > > identical on any host.
> > There needs to be a way to override the target triple that is not creating 
> > prefixed a symlink to ld.lld. Otherwise I can't use NetBSD ld.lld to build 
> > a non-NetBSD target without giving a value for every config option that lld 
> > supports.
> > 
> > I think there should be a command line option to override the triple (e.g. 
> > --triple= or --target=).
> > Also how will the default this interact with input files that have the 
> > OSABI field set? I feel like the options based on the target OSABI should 
> > be used instead of the default triple.
> OSABI field is not reliable way to detect OS/ABI. Everybody except FreeBSD 
> sets UNIX SystemV.
Actually there is a FreeBSD specific hack to detect emulation name, and it has 
suffix `fbsd`.. if it is detected it sets FreeBSD OSABI.

We don't have a chance to use a similar hack for NetBSD in other configuration 
options.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:770
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+

arichardson wrote:
> arichardson wrote:
> > If I invoke an unprefixed ld.lld on NetBSD but want to target a different 
> > operating system, this will cause all the NetBSD defaults to apply to that 
> > binary and will possibly cause it to crash at runtime.
> > 
> > I think any config changes based on a triple would need to use an explicit 
> > --target= flag instead. As @ruiu says, LLD's behaviour should not change 
> > depending on the host OS/default LLVM triple. Given the same input files 
> > and command line options the resulting binary should be identical on any 
> > host.
> There needs to be a way to override the target triple that is not creating 
> prefixed a symlink to ld.lld. Otherwise I can't use NetBSD ld.lld to build a 
> non-NetBSD target without giving a value for every config option that lld 
> supports.
> 
> I think there should be a command line option to override the triple (e.g. 
> --triple= or --target=).
> Also how will the default this interact with input files that have the OSABI 
> field set? I feel like the options based on the target OSABI should be used 
> instead of the default triple.
OSABI field is not reliable way to detect OS/ABI. Everybody except FreeBSD sets 
UNIX SystemV.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Alexander Richardson via Phabricator via cfe-commits]

arichardson requested changes to this revision.
arichardson added inline comments.
This revision now requires changes to proceed.



Comment at: ELF/Driver.cpp:770
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+

arichardson wrote:
> If I invoke an unprefixed ld.lld on NetBSD but want to target a different 
> operating system, this will cause all the NetBSD defaults to apply to that 
> binary and will possibly cause it to crash at runtime.
> 
> I think any config changes based on a triple would need to use an explicit 
> --target= flag instead. As @ruiu says, LLD's behaviour should not change 
> depending on the host OS/default LLVM triple. Given the same input files and 
> command line options the resulting binary should be identical on any host.
There needs to be a way to override the target triple that is not creating 
prefixed a symlink to ld.lld. Otherwise I can't use NetBSD ld.lld to build a 
non-NetBSD target without giving a value for every config option that lld 
supports.

I think there should be a command line option to override the triple (e.g. 
--triple= or --target=).
Also how will the default this interact with input files that have the OSABI 
field set? I feel like the options based on the target OSABI should be used 
instead of the default triple.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny updated this revision to Diff 181268.
mgorny added a comment.

Implemented checking the triple against target registry. Also made `--version` 
output the detected target.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215

Files:
  ELF/Config.h
  ELF/Driver.cpp
  ELF/Driver.h

Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -31,7 +31,9 @@
   void addLibrary(StringRef Name);
 
 private:
+  void setDefaultTargetTriple(StringRef argv0);
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -54,6 +54,7 @@
 #include "llvm/Support/LEB128.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/TarWriter.h"
+#include "llvm/Support/TargetRegistry.h"
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -365,6 +366,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->EMachine) {
+  case EM_386:
+Config->SearchPaths.push_back("=/usr/lib/i386");
+break;
+  case EM_X86_64:
+break;
+  // TODO: support non-x86 architectures
+}
+Config->SearchPaths.push_back("=/usr/lib");
+  }
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -378,6 +396,26 @@
 return;
   }
 
+  if (const char *Path = getReproduceOption(Args)) {
+// Note that --reproduce is a debug option so you can ignore it
+// if you are trying to understand the whole picture of the code.
+Expected> ErrOrWriter =
+TarWriter::create(Path, path::stem(Path));
+if (ErrOrWriter) {
+  Tar = std::move(*ErrOrWriter);
+  Tar->append("response.txt", createResponseFile(Args));
+  Tar->append("version.txt", getLLDVersion() + "\n");
+} else {
+  error("--reproduce: " + toString(ErrOrWriter.takeError()));
+}
+  }
+
+  initLLVM();
+  setDefaultTargetTriple(ArgsArr[0]);
+  readConfigs(Args);
+  checkZOptions(Args);
+  appendDefaultSearchPaths();
+
   // Handle -v or -version.
   //
   // A note about "compatible with GNU linkers" message: this is a hack for
@@ -393,26 +431,11 @@
   // lot of "configure" scripts out there that are generated by old version
   // of Libtool. We cannot convince every software developer to migrate to
   // the latest version and re-generate scripts. So we have this hack.
-  if (Args.hasArg(OPT_v) || Args.hasArg(OPT_version))
+  if (Args.hasArg(OPT_v) || Args.hasArg(OPT_version)) {
 message(getLLDVersion() + " (compatible with GNU linkers)");
-
-  if (const char *Path = getReproduceOption(Args)) {
-// Note that --reproduce is a debug option so you can ignore it
-// if you are trying to understand the whole picture of the code.
-Expected> ErrOrWriter =
-TarWriter::create(Path, path::stem(Path));
-if (ErrOrWriter) {
-  Tar = std::move(*ErrOrWriter);
-  Tar->append("response.txt", createResponseFile(Args));
-  Tar->append("version.txt", getLLDVersion() + "\n");
-} else {
-  error("--reproduce: " + toString(ErrOrWriter.takeError()));
-}
+message("Target: " + Config->TargetTriple.str());
   }
 
-  readConfigs(Args);
-  checkZOptions(Args);
-
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
   if (Args.hasArg(OPT_v) && !Args.hasArg(OPT_INPUT))
@@ -420,7 +443,6 @@
   if (Args.hasArg(OPT_version))
 return;
 
-  initLLVM();
   createFiles(Args);
   if (errorCount())
 return;
@@ -746,6 +768,21 @@
   error(Msg + ": " + StringRef(Err).trim());
 }
 
+void LinkerDriver::setDefaultTargetTriple(StringRef argv0) {
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+
+  // Try to override triple with program name prefix
+  std::string ProgName = llvm::sys::path::stem(argv0);
+  size_t LastComponent = ProgName.rfind('-');
+  if (LastComponent != std::string::npos) {
+std::string Prefix = ProgName.substr(0, LastComponent);
+std::string IgnoredError;
+if (llvm::TargetRegistry::lookupTarget(Prefix, IgnoredError))
+  Config->TargetTriple = llvm::Triple(Prefix);
+  }
+}
+
 // Initializes Config members by the command line options.
 void LinkerDriver::readConfigs(opt::InputArgList ) {
   errorHandler().Verbose = 

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added inline comments.



Comment at: ELF/Driver.cpp:779
+// TODO: verify the triple somehow?
+Config->TargetTriple = llvm::Triple(Prefix);
+  }

mgorny wrote:
> joerg wrote:
> > See ToolChain::getTargetAndModeFromProgramName in clang.
> Yes, I've based this on stripped down version of that. Most notably, I wasn't 
> able to verify triple against TargetRegistry since it isn't initialized here.
initLLVM is called too late. That should be all that is needed to do a proper 
look up.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@joerg if you think that this patch is OK, please click accept so we can be 
aware that this is what you want.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny updated this revision to Diff 180886.
mgorny added a comment.

Adjusted to make paths sysroot-relative.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215

Files:
  ELF/Config.h
  ELF/Driver.cpp
  ELF/Driver.h


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -31,7 +31,9 @@
   void addLibrary(StringRef Name);
 
 private:
+  void setDefaultTargetTriple(StringRef argv0);
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->EMachine) {
+  case EM_386:
+Config->SearchPaths.push_back("=/usr/lib/i386");
+break;
+  case EM_X86_64:
+break;
+  // TODO: support non-x86 architectures
+}
+Config->SearchPaths.push_back("=/usr/lib");
+  }
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -410,8 +427,10 @@
 }
   }
 
+  setDefaultTargetTriple(ArgsArr[0]);
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
@@ -746,6 +765,21 @@
   error(Msg + ": " + StringRef(Err).trim());
 }
 
+void LinkerDriver::setDefaultTargetTriple(StringRef argv0) {
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+
+  // Try to override triple with program name prefix
+  std::string ProgName = llvm::sys::path::stem(argv0);
+  size_t LastComponent = ProgName.rfind('-');
+  if (LastComponent != std::string::npos) {
+std::string Prefix = ProgName.substr(0, LastComponent);
+std::string IgnoredError;
+// TODO: verify the triple somehow?
+Config->TargetTriple = llvm::Triple(Prefix);
+  }
+}
+
 // Initializes Config members by the command line options.
 void LinkerDriver::readConfigs(opt::InputArgList ) {
   errorHandler().Verbose = Args.hasArg(OPT_verbose);
Index: ELF/Config.h
===
--- ELF/Config.h
+++ ELF/Config.h
@@ -14,6 +14,7 @@
 #include "llvm/ADT/MapVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CodeGen.h"
@@ -276,6 +277,10 @@
 
   // 4 for ELF32, 8 for ELF64.
   int Wordsize;
+
+  // Target triple, inferred from program name or defaulted to LLVM
+  // default target.
+  llvm::Triple TargetTriple;
 };
 
 // The only instance of Configuration struct.


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -31,7 +31,9 @@
   void addLibrary(StringRef Name);
 
 private:
+  void setDefaultTargetTriple(StringRef argv0);
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->EMachine) {
+  case EM_386:
+Config->SearchPaths.push_back("=/usr/lib/i386");
+break;
+  case EM_X86_64:
+break;
+  // TODO: support non-x86 architectures
+}
+Config->SearchPaths.push_back("=/usr/lib");
+  }
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -410,8 +427,10 @@
 }
   }
 
+  setDefaultTargetTriple(ArgsArr[0]);
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
@@ -746,6 +765,21 @@
   error(Msg + ": " + 

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Wed, Jan 09, 2019 at 12:20:06AM +, Kamil Rytarowski via Phabricator via 
llvm-commits wrote:
> krytarowski added inline comments.
> 
> 
> 
> Comment at: ELF/Driver.cpp:781
> +  }
> +}
> +
> 
> There is need to add a fallback for a native triple.

Not really. That's what the default target is.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:781
+  }
+}
+

There is need to add a fallback for a native triple.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Tue, Jan 08, 2019 at 10:58:37PM +, Alexander Richardson via Phabricator 
via cfe-commits wrote:
> arichardson added inline comments.
> 
> 
> 
> Comment at: ELF/Driver.cpp:770
> +  // Start with a default initial triple
> +  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
> +
> 
> If I invoke an unprefixed ld.lld on NetBSD but want to target a
> different operating system, this will cause all the NetBSD defaults to
> apply to that binary and will possibly cause it to crash at runtime.

...which no different from clang.

> I think any config changes based on a triple would need to use an
> explicit --target= flag instead. As @ruiu says, LLD's behaviour should
> not change depending on the host OS/default LLVM triple. Given the same
> input files and command line options the resulting binary should be
> identical on any host.

That boils down to either "lld is unusable out of the box" or "your
system must look similar enough to a GNU/Linux environment for lld to
work". I don't consider that useful behavior at all.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Alexander Richardson via Phabricator via cfe-commits]

arichardson added inline comments.



Comment at: ELF/Driver.cpp:770
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+

If I invoke an unprefixed ld.lld on NetBSD but want to target a different 
operating system, this will cause all the NetBSD defaults to apply to that 
binary and will possibly cause it to crash at runtime.

I think any config changes based on a triple would need to use an explicit 
--target= flag instead. As @ruiu says, LLD's behaviour should not change 
depending on the host OS/default LLVM triple. Given the same input files and 
command line options the resulting binary should be identical on any host.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

I want to handle NetBSD in the same way as the other operating systems. I'm 
sorry to have been saying no to a few recent patches for NetBSD, but I think 
that's for a good reason, and I don't think you presented a convincing reason 
why we had to handle only NetBSD differently.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added inline comments.



Comment at: ELF/Driver.cpp:381
+}
+Config->SearchPaths.push_back("/usr/lib");
+  }

Those need to be sysroot-relative of course.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

@ruiu: No, it is exactly what you want, since it allows you to point lld into 
the normal sysroot. Cross-compiling is the default case for the NetBSD 
toolchain.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1350134 , @joerg wrote:

> Thanks, this looks like a good starting point.


What's the final state you want?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

To be honest, I don't think I would lgtm a patch that changes lld's default 
behavior depending on host/target only for NetBSD, and it seems like a NetBSD's 
issue rather than an lld's issue. As I said, could you please make an effort to 
pass the flags you need from the compiler driver to the linker just like other 
systems do? That is easy to do, doesn't hurt anyone, probably a good thing to 
do  anyway as it makes options explicit rather than implicit, and solves at 
least most of the problems you have.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

I'm sorry to say this but I don't think this is a good approach. Just like 
changing the default behavior depending on host hurts cross-build and is 
against the policy of the lld driver, changing the default behavior depending 
on the target hurts it too. Imagine that you are doing a cross-build on 
non-NetBSD system to create a NetBSD executable. You definitely want to ignore 
/usr/lib/i386 and /usr/lib on the host system. This patch does the opposite.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny marked an inline comment as done.
mgorny added inline comments.



Comment at: ELF/Driver.cpp:779
+// TODO: verify the triple somehow?
+Config->TargetTriple = llvm::Triple(Prefix);
+  }

joerg wrote:
> See ToolChain::getTargetAndModeFromProgramName in clang.
Yes, I've based this on stripped down version of that. Most notably, I wasn't 
able to verify triple against TargetRegistry since it isn't initialized here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added inline comments.



Comment at: ELF/Driver.cpp:779
+// TODO: verify the triple somehow?
+Config->TargetTriple = llvm::Triple(Prefix);
+  }

See ToolChain::getTargetAndModeFromProgramName in clang.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

Thanks, this looks like a good starting point.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny updated this revision to Diff 180717.
mgorny added a comment.

Next version, based on recognizing NetBSD from triple.

@joerg, is this a better approach?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215

Files:
  ELF/Config.h
  ELF/Driver.cpp
  ELF/Driver.h


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -31,7 +31,9 @@
   void addLibrary(StringRef Name);
 
 private:
+  void setDefaultTargetTriple(StringRef argv0);
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->EMachine) {
+  case EM_386:
+Config->SearchPaths.push_back("/usr/lib/i386");
+break;
+  case EM_X86_64:
+break;
+  // TODO: support non-x86 architectures
+}
+Config->SearchPaths.push_back("/usr/lib");
+  }
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -410,8 +427,10 @@
 }
   }
 
+  setDefaultTargetTriple(ArgsArr[0]);
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
@@ -746,6 +765,21 @@
   error(Msg + ": " + StringRef(Err).trim());
 }
 
+void LinkerDriver::setDefaultTargetTriple(StringRef argv0) {
+  // Start with a default initial triple
+  Config->TargetTriple = llvm::Triple(getDefaultTargetTriple());
+
+  // Try to override triple with program name prefix
+  std::string ProgName = llvm::sys::path::stem(argv0);
+  size_t LastComponent = ProgName.rfind('-');
+  if (LastComponent != std::string::npos) {
+std::string Prefix = ProgName.substr(0, LastComponent);
+std::string IgnoredError;
+// TODO: verify the triple somehow?
+Config->TargetTriple = llvm::Triple(Prefix);
+  }
+}
+
 // Initializes Config members by the command line options.
 void LinkerDriver::readConfigs(opt::InputArgList ) {
   errorHandler().Verbose = Args.hasArg(OPT_verbose);
Index: ELF/Config.h
===
--- ELF/Config.h
+++ ELF/Config.h
@@ -14,6 +14,7 @@
 #include "llvm/ADT/MapVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CodeGen.h"
@@ -276,6 +277,10 @@
 
   // 4 for ELF32, 8 for ELF64.
   int Wordsize;
+
+  // Target triple, inferred from program name or defaulted to LLVM
+  // default target.
+  llvm::Triple TargetTriple;
 };
 
 // The only instance of Configuration struct.


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -31,7 +31,9 @@
   void addLibrary(StringRef Name);
 
 private:
+  void setDefaultTargetTriple(StringRef argv0);
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+  if (Config->TargetTriple.isOSNetBSD()) {
+// NetBSD driver relies on the linker knowing the default search paths.
+// Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+// (NetBSD::NetBSD constructor)
+switch (Config->EMachine) {
+  case EM_386:
+Config->SearchPaths.push_back("/usr/lib/i386");
+break;
+  case EM_X86_64:
+break;
+  // TODO: support non-x86 architectures
+}
+Config->SearchPaths.push_back("/usr/lib");
+  }
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -410,8 +427,10 @@
 }
   }
 
+  setDefaultTargetTriple(ArgsArr[0]);
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Ed Maste via Phabricator via cfe-commits]

emaste added a comment.

> There is a list of 140-150 unsafe (LLD_UNSAFE) packages with LLD.

Some of these are tagged with a PR or comment explaining why they are 
LLD_UNSAFE, but we haven't done it consistently. Some of these 140-150 were 
probably added in the early days of bringing lld into FreeBSD, and added 
without much thought - some could be as easy as differences in -ztext/-znotext 
default.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I've grepped FreeBSD, OpenBSD and pkgsrc.

OpenBSD ports
=

Total 2 packages there have issues with LLD.

  $ grep -r USE_LLD .
  ./devel/libcoap/Makefile:USE_LLD=   No
  ./sysutils/firmware/vmm/Makefile:USE_LLD=   No



FreeBSD ports
=

There is a list of 140-150 unsafe (LLD_UNSAFE) packages with LLD. A
part of the entries on the list are magnified by the same
framework/piece-of-software, but different component of version.

6 ports have documented issues with search paths:

1. pdcurses
2. libds
3. evangeline
4. rexx-regutil
5. otpw
6. installwatch

The list might be incomplete.. but "thousands of monkeys fixing
packages" mentioned is strong overestimation.

pkgsrc
==

It was mentioned in 2017 (!) that rejecting teaching the driver because of 
packages
in pkgsrc that use `LINKER_RPATH_FLAG` (but probably not limited to this
option).

All of that looks like restricted to:

1. GCC,
2. Mercury,
3. GPS,
4. sather,
5. wmutils-core
6. aws

Most of that is probably about unneeded direct call of a linker.
Probably the list might be longer for trickier examples like emacs. (But
emacs seems to have no issues on OpenBSD and FreeBSD).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

In D56215#1345880 , @krytarowski wrote:

> In D56215#1345845 , @ruiu wrote:
>
> > Not sure what I understand the point, but as to make lld work on/for 
> > NetBSD, I wonder if you can just add -L to the command line in the 
> > compiler driver. Isn't a NetBSD triple passed to the compiler driver? If 
> > so, I wonder if you can add a few extra options when invoking the linker.
>
>
> This describes the original patch of passing flags from compiler driver and 
> breaks GNU ld compat. Joerg expects to pass no extra `-L` or 
> `--disable-new-dtags` options, treating lld as a drop-in replacement for GNU 
> ld.


I don't think you would lose anything by passing `-L` and 
`--disable-new-dtags` from compiler driver. These flags wouldn't do any harm to 
GNU linkers.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Fri, Jan 04, 2019 at 02:48:35PM +, Alexander Richardson via Phabricator 
wrote:
> Or if you really need to call the linker directly without specifying
> search paths you could also install a shell script as /usr/bin/ld that
> passes the appropriate flags to /usr/bin/ld.lld?

That's not a honest suggestion, is it?

> I don't think ifdefs in the source code are a good idea. Cross linking
> should just work as expected. But you could look at the OS field in the
> first input ELF file to choose default config options/a different
> emulation for NetBSD.

No, #if is certainly wrong. Using the OS field doesn't work though,
because it is typically not set. I think only FreeBSD ever did.

> The approach we are using in CheriBSD to differentiate between MIPS and
> CHERI pure-capability to either pass an explicitly
> `-m elf_btsmip_cheri_fbsd`/ `-m elf_btsmip_fbsd` or infer whether it is
> CHERI or MIPS based on the e_flags field of the first input file.

Yeah, but introducing new emulation names goes back to having to modify
things, which would defeat the purpose just as well.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1346342 , @arichardson wrote:

> In D56215#1346061 , @mgorny wrote:
>
> > For the record, another option is to actually fix other software not to 
> > call LD directly.
>
>
> Or if you really need to call the linker directly without specifying search 
> paths you could also install a shell script as /usr/bin/ld that passes the 
> appropriate flags to /usr/bin/ld.lld?
>
> I don't think ifdefs in the source code are a good idea. Cross linking should 
> just work as expected. But you could look at the OS field in the first input 
> ELF file to choose default config options/a different emulation for NetBSD.
>
> The approach we are using in CheriBSD to differentiate between MIPS and CHERI 
> pure-capability to either pass an explicitly `-m elf_btsmip_cheri_fbsd`/ `-m 
> elf_btsmip_fbsd` or infer whether it is CHERI or MIPS based on the e_flags 
> field of the first input file.


This would be the best option to use a shell wrapper for someone who needs it, 
but we cannot convince Joerg for almost 2 years.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Fri, Jan 04, 2019 at 05:52:46AM +, Michał Górny via Phabricator via 
llvm-commits wrote:
> mgorny added a comment.
> 
> For the record, another option is to actually fix other software not to call 
> LD directly.

See thousand monkeys. It doesn't really scale.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Alexander Richardson via Phabricator via cfe-commits]

arichardson added a comment.

In D56215#1346061 , @mgorny wrote:

> For the record, another option is to actually fix other software not to call 
> LD directly.


Or if you really need to call the linker directly without specifying search 
paths you could also install a shell script as /usr/bin/ld that passes the 
appropriate flags to /usr/bin/ld.lld?

I don't think ifdefs in the source code are a good idea. Cross linking should 
just work as expected. But you could look at the OS field in the first input 
ELF file to choose default config options/a different emulation for NetBSD.

The approach we are using in CheriBSD to differentiate between MIPS and CHERI 
pure-capability to either pass an explicitly `-m elf_btsmip_cheri_fbsd`/ `-m 
elf_btsmip_fbsd` or infer whether it is CHERI or MIPS based on the e_flags 
field of the first input file.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

For the record, another option is to actually fix other software not to call LD 
directly.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1345845 , @ruiu wrote:

> Not sure what I understand the point, but as to make lld work on/for NetBSD, 
> I wonder if you can just add -L to the command line in the compiler 
> driver. Isn't a NetBSD triple passed to the compiler driver? If so, I wonder 
> if you can add a few extra options when invoking the linker.


This describes the original patch of passing flags from compiler driver and 
breaks GNU ld compat. Joerg expects to pass no extra `-L` or 
`--disable-new-dtags` options, treating lld as a drop-in replacement for GNU ld.

I'm trying to determine how the idea of Joerg can be implemented.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

Not sure what I understand the point, but as to make lld work on/for NetBSD, I 
wonder if you can just add -L to the command line in the compiler driver. 
Isn't a NetBSD triple passed to the compiler driver? If so, I wonder if you can 
add a few extra options when invoking the linker.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Actually I think that we can handle two cases witch a combination of proposals:

- native mode
- cross mode

For the native mode we go for something like:

  #if defined(__NetBSD__)
  #define NATIVE_TARGET LLD_NETBSD
  #else
  ...

and for cross mode read `argv[0]` to detect target triple in program name.

If `argv[0] == ld` we assume native mode and set target to native, otherwise 
try to parse target from `argv[0]`, if the target is not parsable bail out with 
error.

This way we can transplant cc driver information into lld.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1345695 , @ruiu wrote:

> In D56215#1345417 , @joerg wrote:
>
> > Talking from the perspective of having had to deal with thousands of 
> > packages in pkgsrc over the years: it is naive to believe that there isn't 
> > a lot of software that calls the linker directly for various reasons. As 
> > such, it is very important to have a useful configuration in the linker by 
> > default. Such a configuration is by its very nature target specific. This 
> > doesn't mean it can't be done in a cross-compiler friendly way, on the 
> > contrary. Over the years NetBSD has been pushing its toolchain to be as 
> > similar for the native build and a cross-target as reasonable possible. 
> > Modulo the build time choices in the config.h sense, the only difference 
> > between the native and cross tools is the built-in default of the former.
>
>
> It might be naive but I don't think it's too naive. Most programs use ld via 
> cc, and I don't think it is too unreasonable to not implement a host-specific 
> logic for a very small percentage of programs that directly use ld. If we do, 
> that logic would be the same or very similar to the one that we already have 
> in cc. I think we should avoid that duplication of the host-specific config 
> in the toolchain.
>
> I see there are pros and cons to not have host-specific config in ld. That 
> said, if other operating systems can live without host-specific config in 
> lld, why can't NetBSD do? I really don't like to be in a situation where only 
> one operating system have a host-specific config while others don't.


Before we even can start a philosophical dispute, is there some way to even get 
that setup functional in lld? How to check if the target is supposed to be a 
NetBSD binary? @mgorny raised some proposals.. 
https://reviews.llvm.org/D56215#1345563 but all of them seem to be either 
dysfunctional (ifdefs) or hackish (renaming emul names or renaming lld binary 
name to netbsd-*).

Looking at the code of lld, the detection of FreeBSD is done by checking 
emulation name (*fbsd) and anything else by a flag passed to a linker such as 
`--do-something-for-android` (e.g. "use-android-relr-tags")


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 10:26:38PM +, Rui Ueyama via Phabricator via 
cfe-commits wrote:
> I see there are pros and cons to not have host-specific config in ld.
> That said, if other operating systems can live without host-specific
> config in lld, why can't NetBSD do? I really don't like to be in a
> situation where only one operating system have a host-specific config
> while others don't.

They might not care because they use the thousand monkey approach to
software patching. At least for NetBSD, that's certainly man power
that's better spend elsewhere. They might simply have ignored lld so far
for any of the more interesting cases (like supporting multi-abi).
Lots of possible reasons :)

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

In D56215#1345417 , @joerg wrote:

> Talking from the perspective of having had to deal with thousands of packages 
> in pkgsrc over the years: it is naive to believe that there isn't a lot of 
> software that calls the linker directly for various reasons. As such, it is 
> very important to have a useful configuration in the linker by default. Such 
> a configuration is by its very nature target specific. This doesn't mean it 
> can't be done in a cross-compiler friendly way, on the contrary. Over the 
> years NetBSD has been pushing its toolchain to be as similar for the native 
> build and a cross-target as reasonable possible. Modulo the build time 
> choices in the config.h sense, the only difference between the native and 
> cross tools is the built-in default of the former.


It might be naive but I don't think it's too naive. Most programs use ld via 
cc, and I don't think it is too unreasonable to not implement a host-specific 
logic for a very small percentage of programs that directly use ld. If we do, 
that logic would be the same or very similar to the one that we already have in 
cc. I think we should avoid that duplication of the host-specific config in the 
toolchain.

I see there are pros and cons to not have host-specific config in ld. That 
said, if other operating systems can live without host-specific config in lld, 
why can't NetBSD do? I really don't like to be in a situation where only one 
operating system have a host-specific config while others don't.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

  On 03.01.2019 23:15, Joerg Sonnenberger wrote:
  > On Thu, Jan 03, 2019 at 09:38:49PM +, Kamil Rytarowski via Phabricator 
via cfe-commits wrote:
  >> I think that this place is not the right place to bash GNU ld for 
performance issues.
  > 
  > I didn't.
  > 
  >> I will refer just to slides and paper from Ian Lance Taylor to get 
overview why it is unacceptably slow:
  >>
  >> https://www.airs.com/ian/gold-slides.pdf
  >> https://ai.google/research/pubs/pub34417.pdf
  > 
  > We all know that gold and lld are faster. It's a huge step from
  > "somewhat faster" to "unacceptably slow". But that's again a completely
  > separate topic.

I used to waste like an hour daily average, any test-build of a local change 
and break of 5-10 min is `unacceptably slow`.

  >> I will add that (unless nothing changed recently) ignoring lack of
  >> features (like thinlto) GNU ld cannot produce >=4GB executables and
  >> this makes it even more unusable.
  > 
  > That sounds seriously like a troll. I already mentioned DWARF fission
  > for the one reasonable case for > 100MB binaries and that's in short
  > "don't touch most of the data"...
  > 
  
  I've edited the entry above that it's already more than 4GB of unoptimized 
webkit build with debuginfo, and gnu ld is truncating files on 4GB boundary.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 09:38:49PM +, Kamil Rytarowski via Phabricator via 
cfe-commits wrote:
> I think that this place is not the right place to bash GNU ld for performance 
> issues.

I didn't.

> I will refer just to slides and paper from Ian Lance Taylor to get overview 
> why it is unacceptably slow:
> 
> https://www.airs.com/ian/gold-slides.pdf
> https://ai.google/research/pubs/pub34417.pdf

We all know that gold and lld are faster. It's a huge step from
"somewhat faster" to "unacceptably slow". But that's again a completely
separate topic.

> I will add that (unless nothing changed recently) ignoring lack of
> features (like thinlto) GNU ld cannot produce >=4GB executables and
> this makes it even more unusable.

That sounds seriously like a troll. I already mentioned DWARF fission
for the one reasonable case for > 100MB binaries and that's in short
"don't touch most of the data"...

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

  On Thu, Jan 03, 2019 at 08:31:53PM +, Kamil Rytarowski via Phabricator 
via cfe-commits wrote:
  > krytarowski added a comment.
  >
  > On 03.01.2019 21:19, Joerg Sonnenberger wrote:
  >
  >> On Thu, Jan 03, 2019 at 06:34:22PM +, Kamil Rytarowski via Phabricator 
via cfe-commits wrote:
  >>
  >>> krytarowski added a comment.
  >>>
  >>> Actually I find it frustrating and unfair as GNU ld doesn't have builtin
  >>>  knowledge either.. it's passed with gross 'super hack' comments from 
build scripts... but we are forced to push it to lld in order to move on.
  >>
  >> I'm puzzled. Seriously, when was the last time you actually checked how
  >>  much customization contains on a per-OS base in GNU ld? Yes, I'm
  >>  including the various build scripts because GNU ld is generally build by
  >>  a mix of hard-coded logic in the tool itself and various adjustments in
  >>  the linker scripts it is shipped with. But they are all a builtin part
  >>  of GNU ld as far as the end user is concerned. It is pretty much
  >>  irrelevant from a point of functionality where that logic is, but
  >>  skipping is a serious usability issue.
  >>
  >> Joerg
  >
  > I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':
  
  I think that's a left over from old times before the emulparams/* logic
  was done properly. But that's more a case of GNU ld's build system being
  gross than anything else.
  
  Joerg



  On Thu, Jan 03, 2019 at 06:58:41PM +, Kamil Rytarowski via Phabricator 
wrote:
  > But the result is that we don't have GNU gold either and are stuck with
  > 40min linking times of LLVM. It's destructive to productivity and
  > damages any LLVM related development.
  
  The reason noone cared much about GNU gold is that it supports only a
  limited set of platforms and forces a lot of modern GNU "innovations"
  without any chance of fixing them. To a degree, both concerns apply to
  lld as well, but reasonable well integrated LTO support with Clang
  provides at least something in return. I have no idea about your link
  times, the only situation where linking is taking a really significant
  chunk of time is for full debug builds and the general solution for that
  is DWARF fission.
  
  Joerg

Actually I do cared to port gold but it didn't work and I wasn't able to spare 
more time. My work and a fixup for one feature is in pkgsrc-wip.

I think that this place is not the right place to bash GNU ld for performance 
issues.

I will refer just to slides and paper from Ian Lance Taylor to get overview why 
it is unacceptably slow:

https://www.airs.com/ian/gold-slides.pdf
https://ai.google/research/pubs/pub34417.pdf

I will add that (unless nothing changed recently) ignoring lack of features 
(like thinlto) GNU ld cannot produce >=4GB executables and this makes it even 
more unusable.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I think that ifdefining the linker options with `__NetBSD__` is no-go.

In D56215#1345563 , @mgorny wrote:

> We've discussed this a bit and given other changes we need to do, and I see 
> pretty much three options here:
>
> 1. We hardcode stuff under `defined(__NetBSD__)` which kinda solves the 
> problem, except lld won't be very cross-friendly.


I think that ifdefining the linker options with `__NetBSD__` is no-go. We 
expect to get lld to link NetBSD programs from any host, or from NetBSD to any 
other.

> 2. We try to do conditionals based on triple but this works only when we 
> customize the install to include it in executable name. We probably would 
> still need to default based on `defined(__NetBSD__)` when triple isn't 
> available via process name.

I think it won't work for us.

> 3. We create `*nbsd*` emulations for all arches (e.g. amd64/x86 don't have 
> such emulations right now), and use that to switch logic. This would be 
> closer to what FreeBSD does, I think. However, if we do this, then I suppose 
> we should also add similar aliases to GNU ld.

Probably too gross hack just for the gain redesigned model of a linker 
functional.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 08:31:53PM +, Kamil Rytarowski via Phabricator via 
cfe-commits wrote:
> krytarowski added a comment.
> 
> On 03.01.2019 21:19, Joerg Sonnenberger wrote:
> 
> > On Thu, Jan 03, 2019 at 06:34:22PM +, Kamil Rytarowski via Phabricator 
> > via cfe-commits wrote:
> > 
> >> krytarowski added a comment.
> >> 
> >> Actually I find it frustrating and unfair as GNU ld doesn't have builtin
> >>  knowledge either.. it's passed with gross 'super hack' comments from 
> >> build scripts... but we are forced to push it to lld in order to move on.
> > 
> > I'm puzzled. Seriously, when was the last time you actually checked how
> >  much customization contains on a per-OS base in GNU ld? Yes, I'm
> >  including the various build scripts because GNU ld is generally build by
> >  a mix of hard-coded logic in the tool itself and various adjustments in
> >  the linker scripts it is shipped with. But they are all a builtin part
> >  of GNU ld as far as the end user is concerned. It is pretty much
> >  irrelevant from a point of functionality where that logic is, but
> >  skipping is a serious usability issue.
> > 
> > Joerg
> 
> I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':

I think that's a left over from old times before the emulparams/* logic
was done properly. But that's more a case of GNU ld's build system being
gross than anything else.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

We've discussed this a bit and given other changes we need to do, and I see 
pretty much three options here:

1. We hardcode stuff under `defined(__NetBSD__)` which kinda solves the 
problem, except lld won't be very cross-friendly.
2. We try to do conditionals based on triple but this works only when we 
customize the install to include it in executable name. We probably would still 
need to default based on `defined(__NetBSD__)` when triple isn't available via 
process name.
3. We create `*nbsd*` emulations for all arches (e.g. amd64/x86 don't have such 
emulations right now), and use that to switch logic. This would be closer to 
what FreeBSD does, I think. However, if we do this, then I suppose we should 
also add similar aliases to GNU ld.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

On 03.01.2019 21:19, Joerg Sonnenberger wrote:

> On Thu, Jan 03, 2019 at 06:34:22PM +, Kamil Rytarowski via Phabricator 
> via cfe-commits wrote:
> 
>> krytarowski added a comment.
>> 
>> Actually I find it frustrating and unfair as GNU ld doesn't have builtin
>>  knowledge either.. it's passed with gross 'super hack' comments from build 
>> scripts... but we are forced to push it to lld in order to move on.
> 
> I'm puzzled. Seriously, when was the last time you actually checked how
>  much customization contains on a per-OS base in GNU ld? Yes, I'm
>  including the various build scripts because GNU ld is generally build by
>  a mix of hard-coded logic in the tool itself and various adjustments in
>  the linker scripts it is shipped with. But they are all a builtin part
>  of GNU ld as far as the end user is concerned. It is pretty much
>  irrelevant from a point of functionality where that logic is, but
>  skipping is a serious usability issue.
> 
> Joerg

I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':

  # XXX super hack
  . if (${BINUTILS_MACHINE_ARCH} == "x86_64" && \
("${f}" == "elf_i386" || "${f}" == "i386nbsd"))
  EMUL_LIB_PATH.${f}=/usr/lib/i386
  . elif (${BINUTILS_MACHINE_ARCH} == "sparc64" && \
("${f}" == "elf32_sparc" || "${f}" == "sparcnbsd"))
  EMUL_LIB_PATH.${f}=/usr/lib/sparc
  . elif !empty(BINUTILS_MACHINE_ARCH:Mmips64*)
  .  if "${f}" == "elf32ltsmip" || "${f}" == "elf32btsmip"
  EMUL_LIB_PATH.${f}:=/usr/lib/o32
  .  elif "${f}" == "elf64ltsmip" || "${f}" == "elf64btsmip"
  EMUL_LIB_PATH.${f}:=/usr/lib/64
  .  else
  EMUL_LIB_PATH.${f}=/usr/lib
  .  endif
  . else
  EMUL_LIB_PATH.${f}=/usr/lib
  . endif
  
  e${f}.c: ${DIST}/ld/genscripts.sh ${.CURDIR}/Makefile stringify.sed
  ${_MKTARGET_CREATE}
  unset MACHINE || true; \
  LIB_PATH=${EMUL_LIB_PATH.${f}} NATIVE=yes \
  ${HOST_SH} ${DIST}/ld/genscripts.sh ${DIST}/ld \
  ${LIBDIR} "/usr" "/usr/bin" \
  ${G_target_alias} ${G_target_alias} ${G_target_alias} \
  ${G_EMUL} ${LIBDIR} yes ${G_enable_initfini_array} \
  ${f} "${G_target_alias}"

So we are now trying to put the logic directly into lld.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 06:58:41PM +, Kamil Rytarowski via Phabricator 
wrote:
> But the result is that we don't have GNU gold either and are stuck with
> 40min linking times of LLVM. It's destructive to productivity and
> damages any LLVM related development.

The reason noone cared much about GNU gold is that it supports only a
limited set of platforms and forces a lot of modern GNU "innovations"
without any chance of fixing them. To a degree, both concerns apply to
lld as well, but reasonable well integrated LTO support with Clang
provides at least something in return. I have no idea about your link
times, the only situation where linking is taking a really significant
chunk of time is for full debug builds and the general solution for that
is DWARF fission.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via cfe-commits]

On Thu, Jan 03, 2019 at 06:34:22PM +, Kamil Rytarowski via Phabricator via 
cfe-commits wrote:
> krytarowski added a comment.
> 
> Actually I find it frustrating and unfair as GNU ld doesn't have builtin
> knowledge either.. it's passed with gross 'super hack' comments from build 
> scripts... but we are forced to push it to lld in order to move on.

I'm puzzled. Seriously, when was the last time you actually checked how
much customization contains on a per-OS base in GNU ld? Yes, I'm
including the various build scripts because GNU ld is generally build by
a mix of hard-coded logic in the tool itself and various adjustments in
the linker scripts it is shipped with. But they are all a builtin part
of GNU ld as far as the end user is concerned. It is pretty much
irrelevant from a point of functionality where that logic is, but
skipping is a serious usability issue.

Joerg
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny updated this revision to Diff 180121.
mgorny edited the summary of this revision.
mgorny added a comment.

Removed non-x86.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215

Files:
  ELF/Driver.cpp
  ELF/Driver.h


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -32,6 +32,7 @@
 
 private:
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.
+  // Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+  // (NetBSD::NetBSD constructor)
+  switch (Config->EMachine) {
+case EM_386:
+  Config->SearchPaths.push_back("/usr/lib/i386");
+  break;
+case EM_X86_64:
+  break;
+// TODO: support non-x86 architectures
+  }
+  Config->SearchPaths.push_back("/usr/lib");
+#endif
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -412,6 +429,7 @@
 
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -32,6 +32,7 @@
 
 private:
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,23 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.
+  // Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+  // (NetBSD::NetBSD constructor)
+  switch (Config->EMachine) {
+case EM_386:
+  Config->SearchPaths.push_back("/usr/lib/i386");
+  break;
+case EM_X86_64:
+  break;
+// TODO: support non-x86 architectures
+  }
+  Config->SearchPaths.push_back("/usr/lib");
+#endif
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -412,6 +429,7 @@
 
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny marked an inline comment as done.
mgorny added inline comments.



Comment at: ELF/Driver.cpp:369
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.

krytarowski wrote:
> is it possible to use some Triple NetBSD target here?
Technically, you can get triple from process name but that obviously works only 
when lld is run as `$CHOST-lld` and not plain `lld`, which is not really the 
case right now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:369
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.

is it possible to use some Triple NetBSD target here?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:377
+  break;
+case EM_MIPS:
+  if (Config->EKind == ELF64LEKind || Config->EKind == ELF64BEKind)

Please drop MIPS/PPC for now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny updated this revision to Diff 180114.
mgorny edited the summary of this revision.
mgorny added a comment.
Herald added subscribers: atanasyan, sdardis.

Updated to use clang's libdir logic.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215

Files:
  ELF/Driver.cpp
  ELF/Driver.h


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -32,6 +32,7 @@
 
 private:
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,28 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.
+  // Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+  // (NetBSD::NetBSD constructor)
+  switch (Config->EMachine) {
+case EM_386:
+  Config->SearchPaths.push_back("/usr/lib/i386");
+  break;
+case EM_MIPS:
+  if (Config->EKind == ELF64LEKind || Config->EKind == ELF64BEKind)
+Config->SearchPaths.push_back("/usr/lib/64");
+  // TODO: how to detect o32?
+  break;
+case EM_PPC64:
+  break;
+// TODO: add *nbsd* emulations when supported
+  }
+  Config->SearchPaths.push_back("/usr/lib");
+#endif
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -412,6 +434,7 @@
 
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -32,6 +32,7 @@
 
 private:
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,28 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.
+  // Please keep this in sync with clang/lib/Driver/ToolChains/NetBSD.cpp
+  // (NetBSD::NetBSD constructor)
+  switch (Config->EMachine) {
+case EM_386:
+  Config->SearchPaths.push_back("/usr/lib/i386");
+  break;
+case EM_MIPS:
+  if (Config->EKind == ELF64LEKind || Config->EKind == ELF64BEKind)
+Config->SearchPaths.push_back("/usr/lib/64");
+  // TODO: how to detect o32?
+  break;
+case EM_PPC64:
+  break;
+// TODO: add *nbsd* emulations when supported
+  }
+  Config->SearchPaths.push_back("/usr/lib");
+#endif
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -412,6 +434,7 @@
 
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

We will prepare a patch for i386 x86_64 only for now. Until we will get lld 
fully functional on NetBSD/amd64 we will skip other architectures.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

Talking from the perspective of having had to deal with thousands of packages 
in pkgsrc over the years: it is naive to believe that there isn't a lot of 
software that calls the linker directly for various reasons. As such, it is 
very important to have a useful configuration in the linker by default. Such a 
configuration is by its very nature target specific. This doesn't mean it can't 
be done in a cross-compiler friendly way, on the contrary. Over the years 
NetBSD has been pushing its toolchain to be as similar for the native build and 
a cross-target as reasonable possible. Modulo the build time choices in the 
config.h sense, the only difference between the native and cross tools is the 
built-in default of the former.

Clang works extremely well in that regard and perfectly supports a universal 
toolchain. LLD should as well. Consistent behavior of ELF across different OS 
is a fiction, as such some OS and/or CPU family specific defaults are naturally 
different. This can be grouped in general:
(1) The target operating system specified either from the builtin default, the 
name of the tool (triple-ld), an option like clang's --target or if desirable 
the name of the emulation when specified. I don't have a strong reason for 
supporting the last as it is typically not unique even with binutils and more a 
case of historic legacy than useful feature. For the perspective of supporting 
both native and cross toolchains, the first three options are enough and when 
using the compiler driver, the first two will generally work fine.
(2) The target CPU family. While it can be partially guessed from the object 
files, there are fun expects. ARM instruction encodings are one of the 
pecularities a linker has to deal with for example. Is BX a valid jump 
instruction?
(3) Whether the target CPU family is the primary ABI. This can generally not be 
determined from the object files and can affect the default search paths. Hard 
vs soft floating point is a good example here. Other cases are easier like 
linking i386 binaries on x86_64. N32 vs N64 on MIPS is more difficult again. 
This is a bit tricky in that it often can be drived only from the emulation 
name.

In terms of architecture, it doesn't need much, but it needs some thought. 
Identifying the target OS is likely the easiest. Most of the rest is OS 
specific adjustment. Having access to the binary name and the the arguments 
should be enough though. Doing it properly avoids the fun of having to patch a 
lot of software without costing that much in terms of code.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1345400 , @ruiu wrote:

> Joerg, what is special about NetBSD?


Nothing.

But the result is that we don't have GNU gold either and are stuck with 40min 
linking times of LLVM. It's destructive to productivity and damages any LLVM 
related development.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

I sympathize and understand your frustration, but I don't know what I can do to 
you. The thing that lld doesn't have host-specific config is a policy matter 
we've been maintaining so far for all operating systems. I don't think NetBSD 
should be the only exception of the policy. In addition to that, I strongly 
believe the fact that lld's behavior only depends on the command line options 
given to the linker is easier to understand and generally a good thing.

Joerg, what is special about NetBSD?


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Actually I find it frustrating and unfair as GNU ld doesn't have builtin 
knowledge either.. it's passed with gross 'super hack' comments from build 
scripts... but we are forced to push it to lld in order to move on.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

It's an option but Joerg insists on using lld standalone.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

As you can see, lld doesn't really have any host-dependent knowledge so far, 
even though there are a few OSes that use lld as the default linker. We've 
added host-dependent knowledge to the compiler driver instead of to the linker 
for various operating systems. I guess that we could do the same thing for 
NetBSD, no?


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1345326 , @ruiu wrote:

> In D56215#1344279 , @krytarowski 
> wrote:
>
> > In D56215#1344233 , @ruiu wrote:
> >
> > > lld's driver is intentionally designed to be agnostic of the host that 
> > > the linker is running for the reasons described at the beginning of 
> > > Driver.cpp: 
> > > https://github.com/llvm-project/lld/blob/master/ELF/Driver.cpp#L13 I 
> > > think I like that approach. If you need to do this, you can do this in 
> > > the compiler driver rather than in the linker itself. Is there any reason 
> > > you need to do this in the linker?
> >
> >
> > This breaks compat with GNU ld here and the linker is intended to be used 
> > standalone.
>
>
> This is where lld is not 100% compatible with GNU ld, but I'd think that's 
> not a bad thing. I'd like to make lld agnostics of host OS so that the linker 
> works exactly in the same way on any operating systems, which makes cross 
> linking much easier to do. So, both a run-time detection of a host OS or a 
> configure-time customization are I think undesirable.


Personally I have no strong opinion either way. Joerg is blocking a patch to 
handle it in clang: https://reviews.llvm.org/D33726

I find it very silly reason to brick NetBSD support in lld. I expect that it's 
easier to push paths into lld than convince @joerg to accept clang patch.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

In D56215#1344279 , @krytarowski wrote:

> In D56215#1344233 , @ruiu wrote:
>
> > lld's driver is intentionally designed to be agnostic of the host that the 
> > linker is running for the reasons described at the beginning of Driver.cpp: 
> > https://github.com/llvm-project/lld/blob/master/ELF/Driver.cpp#L13 I think 
> > I like that approach. If you need to do this, you can do this in the 
> > compiler driver rather than in the linker itself. Is there any reason you 
> > need to do this in the linker?
>
>
> This breaks compat with GNU ld here and the linker is intended to be used 
> standalone.


This is where lld is not 100% compatible with GNU ld, but I'd think that's not 
a bad thing. I'd like to make lld agnostics of host OS so that the linker works 
exactly in the same way on any operating systems, which makes cross linking 
much easier to do. So, both a run-time detection of a host OS or a 
configure-time customization are I think undesirable.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I assume that we need to reimplement this in the context of lld:

  NetBSD::NetBSD(const Driver , const llvm::Triple , const ArgList 
)
  : Generic_ELF(D, Triple, Args) {
if (!Args.hasArg(options::OPT_nostdlib)) {
  // When targeting a 32-bit platform, try the special directory used on
  // 64-bit hosts, and only fall back to the main library directory if that
  // doesn't work.
  // FIXME: It'd be nicer to test if this directory exists, but I'm not sure
  // what all logic is needed to emulate the '=' prefix here.
  switch (Triple.getArch()) {
  case llvm::Triple::x86:
getFilePaths().push_back("=/usr/lib/i386");
break;
  case llvm::Triple::arm:
  case llvm::Triple::armeb:
  case llvm::Triple::thumb:
  case llvm::Triple::thumbeb:
switch (Triple.getEnvironment()) {
case llvm::Triple::EABI:
case llvm::Triple::GNUEABI:
  getFilePaths().push_back("=/usr/lib/eabi");
  break;
case llvm::Triple::EABIHF:
case llvm::Triple::GNUEABIHF:
  getFilePaths().push_back("=/usr/lib/eabihf");
  break;
default:
  getFilePaths().push_back("=/usr/lib/oabi");
  break;
}
break;
  case llvm::Triple::mips64:
  case llvm::Triple::mips64el:
if (tools::mips::hasMipsAbiArg(Args, "o32"))
  getFilePaths().push_back("=/usr/lib/o32");
else if (tools::mips::hasMipsAbiArg(Args, "64"))
  getFilePaths().push_back("=/usr/lib/64");
break;
  case llvm::Triple::ppc:
getFilePaths().push_back("=/usr/lib/powerpc");
break;
  case llvm::Triple::sparc:
getFilePaths().push_back("=/usr/lib/sparc");
break;
  default:
break;
  }
  
  getFilePaths().push_back("=/usr/lib");
}
  }

https://github.com/llvm-mirror/clang/blob/e030444510df2ffaf23eeae35692dc363bc28439/lib/Driver/ToolChains/NetBSD.cpp#L334-L379


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1344317 , @joerg wrote:

> In D56215#1344279 , @krytarowski 
> wrote:
>
> > In D56215#1344183 , @joerg wrote:
> >
> > > This doesn't seem a reasonable approach at all:
> > >
> > > (1) It breaks cross-linking.
> > >  (2) It is not correct for any target architecture, e.g. /usr/local/lib 
> > > certainly doesn't belong on this list and /lib doesn't either.
> > >  (3) The correct list depends not only on the target architecture, but 
> > > also the active emulation.
> >
> >
> > Is it acceptable to pass all the paths through configure/build phase of 
> > lld? It's done this way in GNU ld in the NetBSD distribution. If we need or 
> > want to hardcode all the specific paths it will be harder to maintain the 
> > proper list and behavior inside lld.
>
>
> I don't think that would be better either. The main point is that it needs a 
> lot more architectural knowledge than shown in the path. I would expect e.g. 
> Linux distros have a similar problem nowadays.


What's the expected solution?

This is a blocker to move on.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

In D56215#1344279 , @krytarowski wrote:

> In D56215#1344183 , @joerg wrote:
>
> > This doesn't seem a reasonable approach at all:
> >
> > (1) It breaks cross-linking.
> >  (2) It is not correct for any target architecture, e.g. /usr/local/lib 
> > certainly doesn't belong on this list and /lib doesn't either.
> >  (3) The correct list depends not only on the target architecture, but also 
> > the active emulation.
>
>
> Is it acceptable to pass all the paths through configure/build phase of lld? 
> It's done this way in GNU ld in the NetBSD distribution. If we need or want 
> to hardcode all the specific paths it will be harder to maintain the proper 
> list and behavior inside lld.


I don't think that would be better either. The main point is that it needs a 
lot more architectural knowledge than shown in the path. I would expect e.g. 
Linux distros have a similar problem nowadays.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56215#1344233 , @ruiu wrote:

> lld's driver is intentionally designed to be agnostic of the host that the 
> linker is running for the reasons described at the beginning of Driver.cpp: 
> https://github.com/llvm-project/lld/blob/master/ELF/Driver.cpp#L13 I think I 
> like that approach. If you need to do this, you can do this in the compiler 
> driver rather than in the linker itself. Is there any reason you need to do 
> this in the linker?


This breaks compat with GNU ld here and the linker is intended to be used 
standalone.

In D56215#1344183 , @joerg wrote:

> This doesn't seem a reasonable approach at all:
>
> (1) It breaks cross-linking.
>  (2) It is not correct for any target architecture, e.g. /usr/local/lib 
> certainly doesn't belong on this list and /lib doesn't either.
>  (3) The correct list depends not only on the target architecture, but also 
> the active emulation.


Is it acceptable to pass all the paths through configure/build phase of lld? 
It's done this way in GNU ld in the NetBSD distribution. If we need or want to 
hardcode all the specific paths it will be harder to maintain the proper list 
and behavior inside lld.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Rui Ueyama via Phabricator via cfe-commits]

ruiu added a comment.

lld's driver is intentionally designed to be agnostic of the host that the 
linker is running for the reasons described at the beginning of Driver.cpp: 
https://github.com/llvm-project/lld/blob/master/ELF/Driver.cpp#L13 I think I 
like that approach. If you need to do this, you can do this in the compiler 
driver rather than in the linker itself. Is there any reason you need to do 
this in the linker?


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

This doesn't seem a reasonable approach at all:

(1) It breaks cross-linking.
(2) It is not correct for any target architecture, e.g. /usr/local/lib 
certainly doesn't belong on this list and /lib doesn't either.
(3) The correct list depends not only on the target architecture, but also the 
active emulation.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56215/new/

https://reviews.llvm.org/D56215



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Michał Górny via Phabricator via cfe-commits]

mgorny created this revision.
mgorny added reviewers: krytarowski, joerg, ruiu, grimar, espindola.
mgorny added a project: lld.
Herald added subscribers: llvm-commits, MaskRay, arichardson, emaste.

The NetBSD clang driver relies on NetBSD ld knowing the default search
paths and never passes those paths explicitly.  As a result of this
design requirement, implement appending default search paths within lld
as well.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D56215

Files:
  ELF/Driver.cpp
  ELF/Driver.h


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -32,6 +32,7 @@
 
 private:
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,15 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.
+  Config->SearchPaths.push_back("/usr/local/lib");
+  Config->SearchPaths.push_back("/lib");
+  Config->SearchPaths.push_back("/usr/lib");
+#endif
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -412,6 +421,7 @@
 
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.


Index: ELF/Driver.h
===
--- ELF/Driver.h
+++ ELF/Driver.h
@@ -32,6 +32,7 @@
 
 private:
   void readConfigs(llvm::opt::InputArgList );
+  void appendDefaultSearchPaths();
   void createFiles(llvm::opt::InputArgList );
   void inferMachineType();
   template  void link(llvm::opt::InputArgList );
Index: ELF/Driver.cpp
===
--- ELF/Driver.cpp
+++ ELF/Driver.cpp
@@ -365,6 +365,15 @@
   error("unknown -z value: " + StringRef(Arg->getValue()));
 }
 
+void LinkerDriver::appendDefaultSearchPaths() {
+#if defined(__NetBSD__)
+  // NetBSD driver relies on the linker knowing the default search paths.
+  Config->SearchPaths.push_back("/usr/local/lib");
+  Config->SearchPaths.push_back("/lib");
+  Config->SearchPaths.push_back("/usr/lib");
+#endif
+}
+
 void LinkerDriver::main(ArrayRef ArgsArr) {
   ELFOptTable Parser;
   opt::InputArgList Args = Parser.parse(ArgsArr.slice(1));
@@ -412,6 +421,7 @@
 
   readConfigs(Args);
   checkZOptions(Args);
+  appendDefaultSearchPaths();
 
   // The behavior of -v or --version is a bit strange, but this is
   // needed for compatibility with GNU linkers.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits