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

Thu Jan 3 13:38:49 PST 2019

krytarowski added a comment.

  On Thu, Jan 03, 2019 at 08:31:53PM +0000, 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 +0000, 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 +0000, 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