[PATCH] D73245: Depend stddef.h to provide max_align_t for C++11 and provide better fallback in

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: libcxx/include/new:240
   return __align > __STDCPP_DEFAULT_NEW_ALIGNMENT__;
+#elif defined(_LIBCPP_CXX03_LANG)
+  return __align > alignment_of<__libcpp_max_align_t>::value;

ldionne wrote:
> joerg wrote:
> > ldionne wrote:
> > > So, IIUC what you're saying, `__STDCPP_DEFAULT_NEW_ALIGNMENT__` is 
> > > provided by recent Clangs in C++03 mode? I tested it and it does seem to 
> > > be correct. (side note: I tend to think we should be more aggressive to 
> > > remove old compiler support, since most people don't upgrade their stdlib 
> > > without upgrading their compiler anyway).
> > > 
> > > So if we don't care about supporting old compilers that don't provide 
> > > that macro, we could just get rid of this `#elif`, and such compilers 
> > > would error out when trying to use `max_align_t` in the `#else` below. 
> > > That appears reasonable to me.
> > > 
> > > We'd still leave the `#if TEST_STD_VER >= 11` in the tests below, since 
> > > in C++03 we wouldn't provide `std::max_align_t`, however testing that we 
> > > use overaligned new in the same conditions in C++03 and C++11 becomes 
> > > trivial, because it's the same code path.
> > > 
> > > Did I get what you meant correctly? If so, that sounds like a viable path 
> > > forward to me, since we're simplifying the code. We're also improving on 
> > > our C++03 conformance, which isn't considered good but is certainly not 
> > > considered bad either.
> > Correct, it has been provided since clang 4.0 at least it seems. For 
> > testing, we have two cases, some that specifically check properties of 
> > max_align_t and those should be restricted to C++11 and newer. I think we 
> > should grow a new check that max_align_t <= 
> > __STDCPP_DEFAULT_NEW_ALIGNMENT__ as sanity check, but that's slightly OT. 
> > Most of the existing cases to check for overalignment already use 
> > __STDCPP_DEFAULT_NEW_ALIGNMENT__ anyway, so it would be a case-by-case 
> > check for those.
> I'm fine with that direction if you're willing to update the patch. I'll 
> review it.
Do I understand it correctly that instead of `__libcpp_max_align_t` (or 
(over)exposed `max_align_t`) we can rely entirely on 
`__STDCPP_DEFAULT_NEW_ALIGNMENT__`?


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

https://reviews.llvm.org/D73245



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

LLVM Release Schedule: 10.0.0: Jan 15, 2020: branch, then rc1

It would be nice to get a reply to my mail proposal before the branch.. so we 
could push the code for LLVM 10. (If it was lost, I can resend it) It can 
likely upset both sides, but with the proposal in the end we get a bfd.ld 
drop-in replacement. (One of LLVM goals was to be a drop-in replacement for GNU 
toolchain components, even if some of them are irrelevant on a number of 
platforms.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@MaskRay I will mail you off-list with one question.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.
Herald added a subscriber: arichardson.

Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Stating it from a different side. If you do not care about GNU ld drop-in 
replacement property for Linux it's not our business, but we do care about this 
in NetBSD and we restrict this to our project only (from ELF targets).  If you 
do not care about NetBSD, you shall not care how and whether we use LLD. We try 
hard to not interfere with Linux looking for a consensus.

You are not forced to use the NetBSD driver neither define it in 
`LLD_SYMLINKS_TO_CREATE`. If you have a strong disrespect to this GNU ld 
drop-in replacement approach, I can patch the `die("")` invocation in `main()` 
to conditionally print `"nb.lld"`. There are around 20 lines patches in the 
generic code and around 1/3 of that is in the code comments. This shall not be 
burden for any of you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@joerg works on the ELF loader and we just need to wait for him. We wrote our 
temporary patch, but it was not ideal as the long term solution.

compiler-rt is nicely maintained from our perspective and we have almost 
feature parity with Linux.

We maintain and develop around 4000 NetBSD specific LOC in LLDB. That number 
grows, especially with each CPU architecture gaining upstream support.

> it seems NetBSD just needs

This is not everything, but I don't want to derail yet another review into 
offtopic or generic discussion. Getting lld functional standalone is merely a 
starting point for us.

We need a linker that is a GNU ld drop-in replacement. As we have no interest 
in fixing it for Linux, we want this property for NetBSD.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

We attempted to patch internally LLD rebasing our code for the buildbot 
purposes but LLD without being used rots quickly, see: 
https://reviews.llvm.org/D58892

We use LD as `ld` and there are no plans neither intentions to break it. It was 
already decided internally in the project.

If you insist, I can rewrite nb.lld from C++ to shell and upstream to the LLD 
repository. We require `-fuse-ld=lld` to be rerouted through this shell script 
and lld invocation call it so we can revert back to the concept from 
https://reviews.llvm.org/D69755. Personally I see no gain in this as I prefer 
to rely on LLVM libs at least for Target Triplet detection.

As I can understand that Linux/GNU behavior is promoted (and enforced to other 
ELF OSs) it does not work for us. I propose a patch that keeps intact the 
GNU/Linux code.

If 200 LOC for NetBSD is a show stopper, please see e.g. compiler-rt where we 
maintain 2 orders of magnitude more NetBSD-only LOC.

I try to avoid forking LLD for downstream and this shall be appreciated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70958: [compiler-rt] [test] Disable ASLR on ASAN/MSAN/TSAN tests on NetBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: compiler-rt/test/sanitizer_common/netbsd_commands/run_noaslr.sh:4
+PATH=${PATH}:/usr/sbin
+paxctl +a "${1}"
+exec "${@}"

eugenis wrote:
> krytarowski wrote:
> > I propose to use `/usr/bin/paxctl` as it will be PATH and environment 
> > independent. We already use this direct path approach in pkgsrc.
> It this path correct? /usr/sbin in the code vs /usr/bin in the comment.
It is correct. I made a typo.


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

https://reviews.llvm.org/D70958



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

[PATCH] D70958: [compiler-rt] [test] Disable ASLR on ASAN/MSAN/TSAN tests on NetBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D70958#1767912 , @eugenis wrote:

> Could this go into the common lit config in compiler-rt/test?


Do you mean to run this for all tests in compiler-rt? We intend to disable it 
only when needed and prevent leaking regressions that violate ASLR to other 
components of LLVM.

> What is the problem with ASLR in NetBSD? Is this about fixed shadow location 
> conflicts with the binary & library mappings?

PaX ASLR on NetBSD is too aggressive with the layout randomization and we 
cannot predict ranges of the heap and the stack. Next, we cannot map reliably 
the memory used into shadow buffer that crashes in a cryptic way. We are fine 
with disabling ASLR for the sanitizers that need shadow buffers and origins.




Comment at: compiler-rt/test/sanitizer_common/netbsd_commands/run_noaslr.sh:4
+PATH=${PATH}:/usr/sbin
+paxctl +a "${1}"
+exec "${@}"

I propose to use `/usr/bin/paxctl` as it will be PATH and environment 
independent. We already use this direct path approach in pkgsrc.


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

https://reviews.llvm.org/D70958



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a reviewer: chandlerc.
krytarowski added a comment.

Ping?

We are in the process of switching our buildbot to newer NetBSD snapshot (-8 to 
-9) and we keep waiting for this patch to land.

If we could get this patch merged, we could build and link the whole LLVM with 
lld on NetBSD and it would increase the productivity of the bot (better build 
times). Right now we need to maintain hacks to link at most with 2/3 cores, 
while 5/6 ones are idling doing nothing due to enormous RAM consumption of GNU 
ld.

We also upgraded LLVM in the current snapshot to a 10git version, and for the 
next snapshot merged (hopefully 10.0 or early 11git) we could ship it together 
with LLD aboard.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Short summary:

- FreeBSD/OpenBSD ship with mutations of the behavior of ELF/GNU/Linux in 
certain nits, we do the same with our driver.
- MinGW ships with a frontend driver to COFF, we do the same with a driver to 
ELF/GNU/Linux.
- Darwin ships with default search paths, we do the same in our driver.
- NetBSD is not a GNU system, it is a BSD system that differs with 
ELF/GNU/Linux, GNU/Linux is at most an inspiration, none of our project goals 
is about reimplementing Linux. The same applies to MinGW, Darwin etc that do 
not reimplement Linux.

The proposed change does not make anything without prior art.

LLD is practically the last piece of the LLVM toolchain stack without NetBSD 
support. We run the NetBSD buildbot for LLD since 2018 and there are no plans 
to detach it.

We intend to integrate LLD into our distribution, but we first must make it 
work in the upstream version out of the box.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski abandoned this revision.
krytarowski added a comment.

Better patch in https://reviews.llvm.org/D70048


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski updated this revision to Diff 228591.
krytarowski added a comment.

- fix a typo in a comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048

Files:
  clang/lib/Driver/ToolChain.cpp
  lld/CMakeLists.txt
  lld/NetBSD/CMakeLists.txt
  lld/NetBSD/Driver.cpp
  lld/NetBSD/Options.td
  lld/include/lld/Common/Driver.h
  lld/tools/lld/CMakeLists.txt
  lld/tools/lld/lld.cpp

Index: lld/tools/lld/lld.cpp
===
--- lld/tools/lld/lld.cpp
+++ lld/tools/lld/lld.cpp
@@ -10,12 +10,13 @@
 // function is a thin wrapper which dispatches to the platform specific
 // driver.
 //
-// lld is a single executable that contains four different linkers for ELF,
-// COFF, WebAssembly and Mach-O. The main function dispatches according to
-// argv[0] (i.e. command name). The most common name for each target is shown
+// lld is a single executable that contains five different linkers for ELF,
+// NetBSD, COFF, WebAssembly and Mach-O. The main function dispatches according
+// to argv[0] (i.e. command name). The most common name for each target is shown
 // below:
 //
 //  - ld.lld:ELF (Unix)
+//  - nb.lld:ELF (NetBSD)
 //  - ld64:  Mach-O (macOS)
 //  - lld-link:  COFF (Windows)
 //  - ld-wasm:   WebAssembly
@@ -45,6 +46,7 @@
 enum Flavor {
   Invalid,
   Gnu, // -flavor gnu
+  NetBSD,  // -flavor netbsd
   WinLink, // -flavor link
   Darwin,  // -flavor darwin
   Wasm,// -flavor wasm
@@ -58,6 +60,7 @@
 static Flavor getFlavor(StringRef s) {
   return StringSwitch(s)
   .CasesLower("ld", "ld.lld", "gnu", Gnu)
+  .CasesLower("nb.lld", "netbsd", NetBSD)
   .CasesLower("wasm", "ld-wasm", Wasm)
   .CaseLower("link", WinLink)
   .CasesLower("ld64", "ld64.lld", "darwin", Darwin)
@@ -100,10 +103,15 @@
 #endif
 
 #if LLVM_ON_UNIX
-  // Use GNU driver for "ld" on other Unix-like system.
-  if (progname == "ld")
+  // Use GNU or NetBSD driver for "ld" on other Unix-like system.
+  if (progname == "ld") {
+#if defined(__NetBSD__)
+return NetBSD;
+#else
 return Gnu;
 #endif
+  }
+#endif
 
   // Progname may be something like "lld-gnu". Parse it.
   SmallVector v;
@@ -141,7 +149,7 @@
 // and we use it to detect whether we are running tests or not.
 static bool canExitEarly() { return StringRef(getenv("LLD_IN_TEST")) != "1"; }
 
-/// Universal linker main(). This linker emulates the gnu, darwin, or
+/// Universal linker main(). This linker emulates the gnu, netbsd, darwin, or
 /// windows linker based on the argv[0] or -flavor option.
 int main(int argc, const char **argv) {
   InitLLVM x(argc, argv);
@@ -152,6 +160,8 @@
 if (isPETarget(args))
   return !mingw::link(args);
 return !elf::link(args, canExitEarly());
+  case NetBSD:
+return !netbsd::link(args, canExitEarly());
   case WinLink:
 return !coff::link(args, canExitEarly());
   case Darwin:
@@ -160,7 +170,7 @@
 return !wasm::link(args, canExitEarly());
   default:
 die("lld is a generic driver.\n"
-"Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld"
-" (WebAssembly) instead");
+"Invoke ld.lld (Unix), nb.lld (NetBSD), ld64.lld (macOS), lld-link "
+"(Windows), wasm-ld (WebAssembly) instead");
   }
 }
Index: lld/tools/lld/CMakeLists.txt
===
--- lld/tools/lld/CMakeLists.txt
+++ lld/tools/lld/CMakeLists.txt
@@ -12,6 +12,7 @@
   lldCOFF
   lldDriver
   lldELF
+  lldNetBSD
   lldMinGW
   lldWasm
   )
@@ -20,7 +21,7 @@
   RUNTIME DESTINATION bin)
 
 if(NOT LLD_SYMLINKS_TO_CREATE)
-  set(LLD_SYMLINKS_TO_CREATE lld-link ld.lld ld64.lld wasm-ld)
+  set(LLD_SYMLINKS_TO_CREATE lld-link ld.lld nb.lld ld64.lld wasm-ld)
 endif()
 
 foreach(link ${LLD_SYMLINKS_TO_CREATE})
Index: lld/include/lld/Common/Driver.h
===
--- lld/include/lld/Common/Driver.h
+++ lld/include/lld/Common/Driver.h
@@ -28,6 +28,11 @@
   llvm::raw_ostream  = llvm::errs());
 }
 
+namespace netbsd {
+bool link(llvm::ArrayRef args, bool canExitEarly,
+  llvm::raw_ostream  = llvm::errs());
+}
+
 namespace mach_o {
 bool link(llvm::ArrayRef args, bool canExitEarly,
   llvm::raw_ostream  = llvm::errs());
Index: lld/NetBSD/Options.td
===
--- /dev/null
+++ lld/NetBSD/Options.td
@@ -0,0 +1,7 @@
+include "llvm/Option/OptParser.td"
+
+class F: Flag<["--", "-"], name>;
+
+def version: F<"version">, HelpText<"Display the version number and exit">;
+def v: Flag<["-"], "v">, HelpText<"Display the version number">;
+def: Flag<["-"], "V">, Alias, HelpText<"Alias for --version">;
Index: lld/NetBSD/Driver.cpp
===
--- /dev/null
+++ lld/NetBSD/Driver.cpp
@@ -0,0 +1,187 @@
+//===- nb.lld.cpp - NetBSD 

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Another approach to achieve the same goal as previous attempts. It is already 
better as it avoids two forks.

Does this one look like fine for merging?

The previous one for the reference: https://reviews.llvm.org/D69755


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70048



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

[PATCH] D70048: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski created this revision.
krytarowski added reviewers: joerg, mgorny, ruiu, MaskRay.
krytarowski added a project: lld.
Herald added subscribers: llvm-commits, cfe-commits, mstorsjo, fedor.sergeev, 
aheejin, emaste, dschuff.
Herald added projects: clang, LLVM.

The NetBSD target wraps the default Linux/ELF target with OS
specific customization. It is implemented as a light netbsd::link()
module wrapper that mutates arguments in argv[] and calls
elf::link().

This flavor detects the native/current and target Triple based on
argv[0] parsing. This is prerequisite for cross-compilation, in
particular the NetBSD distribution is cross-built always.

The default configuration of the ELF target is tuned for Linux and
there is no way to costomize in-place for the NetBSD target in the
same way as FreeBSD/OpenBSD. FreeBSD whenever needed can check
emulation name ("*_fbsd") and OpenBSD calls its extensions
"PT_OPENBSD_*".

This distinct flavor is needed for NetBSD as:

- the linker MUST work in the standalone mode
- it must be useful with gcc/pcc/others out of the box
- clang NetBSD driver shall not hardcode LLD specific options
- the linker must have support for cross-building
- LLD shall be a drop-in replacement for (NetBSD-patched) GNU ld

There is no code-duplication between the NetBSD and ELF modules.
The NetBSD driver for debugging purposes prints the Target string
for the -v|-V|--version command line argument. There is no functional
or code maintenance change for other Operating Systems, especially
the ELF ones.

Equivalent customization is already done for the Darwin mode. For
instance there are hardcoded default search paths such as "/usr/lib"
and "/Library/Frameworks" in DarwinLdDriver.cpp. There is a prior
art with the MinGW target that similarly wraps coff:link().

This change is a starting point for development of NetBSD support
in LLD.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70048

Files:
  clang/lib/Driver/ToolChain.cpp
  lld/CMakeLists.txt
  lld/NetBSD/CMakeLists.txt
  lld/NetBSD/Driver.cpp
  lld/NetBSD/Options.td
  lld/include/lld/Common/Driver.h
  lld/tools/lld/CMakeLists.txt
  lld/tools/lld/lld.cpp

Index: lld/tools/lld/lld.cpp
===
--- lld/tools/lld/lld.cpp
+++ lld/tools/lld/lld.cpp
@@ -10,12 +10,13 @@
 // function is a thin wrapper which dispatches to the platform specific
 // driver.
 //
-// lld is a single executable that contains four different linkers for ELF,
-// COFF, WebAssembly and Mach-O. The main function dispatches according to
-// argv[0] (i.e. command name). The most common name for each target is shown
+// lld is a single executable that contains five different linkers for ELF,
+// NetBSD, COFF, WebAssembly and Mach-O. The main function dispatches according
+// to argv[0] (i.e. command name). The most common name for each target is shown
 // below:
 //
 //  - ld.lld:ELF (Unix)
+//  - nb.lld:ELF (NetBSD)
 //  - ld64:  Mach-O (macOS)
 //  - lld-link:  COFF (Windows)
 //  - ld-wasm:   WebAssembly
@@ -45,6 +46,7 @@
 enum Flavor {
   Invalid,
   Gnu, // -flavor gnu
+  NetBSD,  // -flavor netbsd
   WinLink, // -flavor link
   Darwin,  // -flavor darwin
   Wasm,// -flavor wasm
@@ -58,6 +60,7 @@
 static Flavor getFlavor(StringRef s) {
   return StringSwitch(s)
   .CasesLower("ld", "ld.lld", "gnu", Gnu)
+  .CasesLower("nb.lld", "netbsd", NetBSD)
   .CasesLower("wasm", "ld-wasm", Wasm)
   .CaseLower("link", WinLink)
   .CasesLower("ld64", "ld64.lld", "darwin", Darwin)
@@ -100,10 +103,15 @@
 #endif
 
 #if LLVM_ON_UNIX
-  // Use GNU driver for "ld" on other Unix-like system.
-  if (progname == "ld")
+  // Use GNU or NetBSD driver for "ld" on other Unix-like system.
+  if (progname == "ld") {
+#if defined(__NetBSD__)
+return NetBSD;
+#else
 return Gnu;
 #endif
+  }
+#endif
 
   // Progname may be something like "lld-gnu". Parse it.
   SmallVector v;
@@ -141,7 +149,7 @@
 // and we use it to detect whether we are running tests or not.
 static bool canExitEarly() { return StringRef(getenv("LLD_IN_TEST")) != "1"; }
 
-/// Universal linker main(). This linker emulates the gnu, darwin, or
+/// Universal linker main(). This linker emulates the gnu, netbsd, darwin, or
 /// windows linker based on the argv[0] or -flavor option.
 int main(int argc, const char **argv) {
   InitLLVM x(argc, argv);
@@ -152,6 +160,8 @@
 if (isPETarget(args))
   return !mingw::link(args);
 return !elf::link(args, canExitEarly());
+  case NetBSD:
+return !netbsd::link(args, canExitEarly());
   case WinLink:
 return !coff::link(args, canExitEarly());
   case Darwin:
@@ -160,7 +170,7 @@
 return !wasm::link(args, canExitEarly());
   default:
 die("lld is a generic driver.\n"
-"Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld"
-" (WebAssembly) instead");
+"Invoke ld.lld (Unix), nb.lld (NetBSD), ld64.lld (macOS), 

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

> burden with the upstream

We are the part of mainstream and have 4 developers in LLVM + few others 
contributing. We run the NetBSD buildbot that builds and runs test of LLD.

http://lab.llvm.org:8014/builders/netbsd-amd64


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755



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

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I don't want to diverge this patch on offtopic or general discussion.

Does it look good for landing? We need this support to be functional out of the 
box and as a part of LLVM. E.g. `clang -fuse-ld=` currently tries to call 
`ld.lld`, with this patch it will go through `nb.lld` as expected.

`--no-rosegment` is fixed with our WIP patches, but we NEED any support in LLD 
as a starting point so we can later just detach it (or add a check for version 
of NetBSD as we need Triple). Later we will the set the options on our own. I 
actually forgot to e.g. disable GNU stack and keep delaying it until the patch 
will land the sources.

We e.g. miss certain `-switches` in LLD, but hard to do anything in LLD without 
starting point. They will be proposed in future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755



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

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D69755#1731394 , @MaskRay wrote:

> I still have the feeling that such configurations should be added to 
> clangDriver/gcc specs or a shell script wrapper of lld.


OK, as you allow now a shell wrapper of lld, this is a progress. nb.lld is a 
C++ wrapper on steroids doing the right job and part of the upstream repo (this 
is required).

We do not allow downstream LLVM/Clang/... patches in our basesystem and keeping 
this code upstream is required. Also from maintenance burden as LLVM APIs 
evolve quickly.

> How do you decide to handle "Handling of indirect shared library 
> dependencies"? It does not seem to be favored by lld contributors.

The modern Linux/GNU behavior is rejected in NetBSD and we keep the traditional 
behavior that is considered by our community as desired.

This is another topic and indeed probably our next major target to get to work 
within LLD.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755



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

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

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



Comment at: lld/tools/nb.lld/nb.lld.cpp:94
+
+  // disable superfluous RUNPATH on NetBSD
+  args.push_back("--disable-new-dtags");

MaskRay wrote:
> You can't use DT_RUNPATH probably because the change `Add support for 
> DT_RUNPATH - it is just the same as we always have treated DT_RPATH.  
> Approved by core.` (2018-12-30) is still considered new. If you do this in 
> clangDriver, you need a comment with a TODO about the migration process.
I am pretty sure that the only reason to pick it was rust (prebuilt snapshot) 
and its hard-coding of RUNPATH. We still want to disable it everywhere always.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755



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

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski updated this revision to Diff 227593.
krytarowski added a comment.

- upload diff with wider context


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755

Files:
  clang/lib/Driver/ToolChain.cpp
  lld/CMakeLists.txt
  lld/tools/lld/lld.cpp
  lld/tools/nb.lld/CMakeLists.txt
  lld/tools/nb.lld/Options.td
  lld/tools/nb.lld/nb.lld.cpp

Index: lld/tools/nb.lld/nb.lld.cpp
===
--- /dev/null
+++ lld/tools/nb.lld/nb.lld.cpp
@@ -0,0 +1,218 @@
+//===- nb.lld.cpp - NetBSD LLD standalone linker --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// The NetBSD flavor of LLD.
+//
+// This code wraps the default ELF/UNIX lld variation with NetBSD specific
+// customization.
+//
+//===--===//
+
+#include "llvm/ADT/Triple.h"
+#include "llvm/Option/ArgList.h"
+#include "llvm/Option/Option.h"
+#include "llvm/Support/Host.h"
+#include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/TargetRegistry.h"
+#include "llvm/Support/TargetSelect.h"
+#include "llvm/Support/WithColor.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+using namespace llvm::sys;
+
+#define LLD_PROGNAME "ld.lld"
+
+namespace {
+enum ID {
+  OPT_INVALID = 0, // This is not an option ID.
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  OPT_##ID,
+#include "Options.inc"
+#undef OPTION
+};
+
+#define PREFIX(NAME, VALUE) const char *const NAME[] = VALUE;
+#include "Options.inc"
+#undef PREFIX
+
+const opt::OptTable::Info InfoTable[] = {
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  {\
+  PREFIX,  NAME,  HELPTEXT,\
+  METAVAR, OPT_##ID,  opt::Option::KIND##Class,\
+  PARAM,   FLAGS, OPT_##GROUP, \
+  OPT_##ALIAS, ALIASARGS, VALUES},
+#include "Options.inc"
+#undef OPTION
+};
+
+class SLLDOptTable : public opt::OptTable {
+public:
+  SLLDOptTable() : OptTable(InfoTable) {}
+};
+} // namespace
+
+static Triple targetTriple;
+
+static void setTargetTriple(StringRef argv0, opt::InputArgList ) {
+  std::string targetError;
+
+  // Firstly, try to get it from 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);
+if (llvm::TargetRegistry::lookupTarget(prefix, targetError)) {
+  targetTriple = llvm::Triple(prefix);
+  return;
+}
+  }
+
+  // Secondly, use the default target triple
+  targetTriple = llvm::Triple(getDefaultTargetTriple());
+}
+
+static void appendSearchPath(std::vector , const char *path) {
+  args.push_back("--library-path");
+  args.push_back(path);
+}
+
+static void appendTargetCustomization(std::vector ) {
+  // force-disable RO segment on NetBSD due to ld.elf_so limitations
+  args.push_back("--no-rosegment");
+
+  // disable superfluous RUNPATH on NetBSD
+  args.push_back("--disable-new-dtags");
+
+  // set default image base address
+  switch (targetTriple.getArch()) {
+  case llvm::Triple::aarch64:
+  case llvm::Triple::aarch64_be:
+args.push_back("--image-base=0x20010");
+break;
+  default:
+break;
+  }
+
+  // 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 (targetTriple.getArch()) {
+  case llvm::Triple::x86:
+appendSearchPath(args, "=/usr/lib/i386");
+break;
+  case llvm::Triple::arm:
+  case llvm::Triple::armeb:
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+switch (targetTriple.getEnvironment()) {
+case llvm::Triple::EABI:
+case llvm::Triple::GNUEABI:
+  appendSearchPath(args, "=/usr/lib/eabi");
+  break;
+case llvm::Triple::EABIHF:
+case llvm::Triple::GNUEABIHF:
+  appendSearchPath(args, "=/usr/lib/eabihf");
+  break;
+default:
+  appendSearchPath(args, "=/usr/lib/oabi");
+  break;
+}
+break;
+#if 0 // TODO
+  case llvm::Triple::mips64:
+  case llvm::Triple::mips64el:
+if 

[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski created this revision.
krytarowski added reviewers: ruiu, joerg, mgorny, MaskRay.
krytarowski added a project: lld.
Herald added subscribers: llvm-commits, cfe-commits, fedor.sergeev, aheejin, 
emaste, dschuff.
Herald added projects: clang, LLVM.

The NetBSD target wraps the default Linux/ELF target with OS specific
customization. It is implemented as a light nb.lld program that
mutates arguments in argv[] and spawns ld.lld.

This flavor detects the native/current and target Triple based on
argv[0] parsing. This is prerequisite for cross-compilation, in
particular the NetBSD distribution is cross-built always.

The default configuration of the ELF target is tuned for Linux and
there is no way to costomize in-place for the NetBSD target in the
same way as FreeBSD/OpenBSD. FreeBSD whenever needed can check
emulation name ("*_fbsd") and OpenBSD calls its extensions
"PT_OPENBSD_*".

This distinct flavor is needed for NetBSD as:

- the linker MUST work in the standalone mode
- it must be useful with gcc/pcc/others out of the box
- clang NetBSD driver shall not hardcode LLD specific options
- the linker must have support for cross-building
- LLD shall be a drop-in replacement for (NetBSD-patched) GNU ld

nb.lld calls internally ld.lld and there is no code-duplication
between nb.lld and ld.lld. There is no functional or code
maintenance change for other Operating Systems, especially the ELF
ones.

Equivalent customization is already done for the Darwin mode. For
instance there are hardcoded default search paths such as "/usr/lib"
and "/Library/Frameworks" in DarwinLdDriver.cpp.

This change is a starting point for development of NetBSD support
in LLD. This is also another approach to achieve the same goal as
mutating the default LLD/ELF target based on Triple, but in a
less invasive way as everything is moved out of LLD to nb.lld now.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69755

Files:
  clang/lib/Driver/ToolChain.cpp
  lld/CMakeLists.txt
  lld/tools/lld/lld.cpp
  lld/tools/nb.lld/CMakeLists.txt
  lld/tools/nb.lld/Options.td
  lld/tools/nb.lld/nb.lld.cpp

Index: lld/tools/nb.lld/nb.lld.cpp
===
--- /dev/null
+++ lld/tools/nb.lld/nb.lld.cpp
@@ -0,0 +1,218 @@
+//===- nb.lld.cpp - NetBSD LLD standalone linker --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// The NetBSD flavor of LLD.
+//
+// This code wraps the default ELF/UNIX lld variation with NetBSD specific
+// customization.
+//
+//===--===//
+
+#include "llvm/ADT/Triple.h"
+#include "llvm/Option/ArgList.h"
+#include "llvm/Option/Option.h"
+#include "llvm/Support/Host.h"
+#include "llvm/Support/InitLLVM.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/TargetRegistry.h"
+#include "llvm/Support/TargetSelect.h"
+#include "llvm/Support/WithColor.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+using namespace llvm::sys;
+
+#define LLD_PROGNAME "ld.lld"
+
+namespace {
+enum ID {
+  OPT_INVALID = 0, // This is not an option ID.
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  OPT_##ID,
+#include "Options.inc"
+#undef OPTION
+};
+
+#define PREFIX(NAME, VALUE) const char *const NAME[] = VALUE;
+#include "Options.inc"
+#undef PREFIX
+
+const opt::OptTable::Info InfoTable[] = {
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  {\
+  PREFIX,  NAME,  HELPTEXT,\
+  METAVAR, OPT_##ID,  opt::Option::KIND##Class,\
+  PARAM,   FLAGS, OPT_##GROUP, \
+  OPT_##ALIAS, ALIASARGS, VALUES},
+#include "Options.inc"
+#undef OPTION
+};
+
+class SLLDOptTable : public opt::OptTable {
+public:
+  SLLDOptTable() : OptTable(InfoTable) {}
+};
+} // namespace
+
+static Triple targetTriple;
+
+static void setTargetTriple(StringRef argv0, opt::InputArgList ) {
+  std::string targetError;
+
+  // Firstly, try to get it from 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);
+if (llvm::TargetRegistry::lookupTarget(prefix, targetError)) {
+  targetTriple = 

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This looks good as an intermediate step to make lld saner.


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

https://reviews.llvm.org/D56554



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

[PATCH] D52386: [Lexer] Add udefined_behavior_sanitizer feature

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.
Herald added a project: LLVM.

This is needed in the NetBSD kernel, more fine-grained checks would be 
acceptable too, but one global feature detection is what I need.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D52386



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

[PATCH] D67719: [clang] [Basic] Enable __has_feature(leak_sanitizer)

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Looks good to me but I will leave the final decision to someone else.


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

https://reviews.llvm.org/D67719



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

[PATCH] D66361: Improve behavior in the case of stack exhaustion.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D66361#1656037 , @rsmith wrote:

> In D66361#1655903 , @krytarowski 
> wrote:
>
> > This change broke on NetBSD.
> >
> > http://lab.llvm.org:8011/builders/netbsd-amd64/builds/22003/steps/run%20unit%20tests/logs/FAIL%3A%20Clang%3A%3Astack-exhaustion.cpp
>
>
> Test disabled for NetBSD in r370801. If you're interested in investigating 
> why this isn't working there, feel free, but this is only a best-effort 
> mitigation for the case where things have already gone wrong, so there are 
> limits to how much effort it makes sense to resolve this.
>
> Does NetBSD set a hard stack rlimit of less than 8MB by any chance?


The stack rlimit is restricted by default to 4MB. The maximum at least on amd64 
is 128MB... but if someone really needs it, it could by bypassed with more 
stacks.

  $ ulimit -a
  time(cpu-seconds)unlimited
  file(blocks) unlimited
  coredump(blocks) unlimited
  data(kbytes) 262144
  stack(kbytes)4096
  lockedmem(kbytes)10847213
  memory(kbytes)   32541640
  nofiles(descriptors) 1024
  processes1024
  threads  1024
  vmemory(kbytes)  unlimited
  sbsize(bytes)unlimited

Should the limit by raised by default in the system?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66361



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

[PATCH] D66361: Improve behavior in the case of stack exhaustion.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This change broke on NetBSD.

http://lab.llvm.org:8011/builders/netbsd-amd64/builds/22003/steps/run%20unit%20tests/logs/FAIL%3A%20Clang%3A%3Astack-exhaustion.cpp

   (view as text)
  
   TEST 'Clang :: SemaTemplate/stack-exhaustion.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 1';   /home/motus/netbsd8/netbsd8/build/bin/clang -cc1 
-internal-isystem /data/motus/netbsd8/netbsd8/build/lib/clang/10.0.0/include 
-nostdsysteminc -verify 
/data/motus/netbsd8/netbsd8/llvm/tools/clang/test/SemaTemplate/stack-exhaustion.cpp
  --
  Exit Code: 139
  
  Command Output (stderr):
  --
  + : 'RUN: at line 1'
  + /home/motus/netbsd8/netbsd8/build/bin/clang -cc1 -internal-isystem 
/data/motus/netbsd8/netbsd8/build/lib/clang/10.0.0/include -nostdsysteminc 
-verify 
/data/motus/netbsd8/netbsd8/llvm/tools/clang/test/SemaTemplate/stack-exhaustion.cpp
  Stack dump:
  0.Program arguments: /home/motus/netbsd8/netbsd8/build/bin/clang -cc1 
-internal-isystem /data/motus/netbsd8/netbsd8/build/lib/clang/10.0.0/include 
-nostdsysteminc -verify 
/data/motus/netbsd8/netbsd8/llvm/tools/clang/test/SemaTemplate/stack-exhaustion.cpp
 
  1.
/data/motus/netbsd8/netbsd8/llvm/tools/clang/test/SemaTemplate/stack-exhaustion.cpp:9:10:
 current parser token ';'
  #0 0x0242038c llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/home/motus/netbsd8/netbsd8/build/bin/clang+0x242038c)
  #1 0x0241e5ee llvm::sys::RunSignalHandlers() 
(/home/motus/netbsd8/netbsd8/build/bin/clang+0x241e5ee)
  #2 0x0241e6ee SignalHandler(int) 
(/home/motus/netbsd8/netbsd8/build/bin/clang+0x241e6ee)
  
/data/motus/netbsd8/netbsd8/build/tools/clang/test/SemaTemplate/Output/stack-exhaustion.cpp.script:
 line 1:  7058 Segmentation fault  (core dumped) 
/home/motus/netbsd8/netbsd8/build/bin/clang -cc1 -internal-isystem 
/data/motus/netbsd8/netbsd8/build/lib/clang/10.0.0/include -nostdsysteminc 
-verify 
/data/motus/netbsd8/netbsd8/llvm/tools/clang/test/SemaTemplate/stack-exhaustion.cpp
  
  --
  
  

Please fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66361



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

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D64488#1606758 , @ro wrote:

> In D64488#1606716 , @krytarowski 
> wrote:
>
> > Something is broken between reviews. and my mailbox as I am not receiving 
> > any e-mails so pinging does not make any effect... no LLVM admin replied to 
> > my questions on this to validate whether my mail was blacklisted or 
> > similar. I have decided  to change server of my mailbox and workaround it.
>
>
> Maybe this is related to other reviews.llvm.org issues during the weekend 
> where you couldn't update reviews with strange table full
>  errors?


I don't know. It lasts for a month or so. I wouldn't have noted this review 
without checking the phabricator page.


Repository:
  rC Clang

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

https://reviews.llvm.org/D64488



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

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Something is broken between reviews. and my mailbox as I am not receiving any 
e-mails so pinging does not make any effect... no LLVM admin replied to my 
questions on this to validate whether my mail was blacklisted or similar. I 
have decided  to change server of my mailbox and workaround it.




Comment at: test/Driver/fsanitize.c:721
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"

Is twice x86_64 expected?


Repository:
  rC Clang

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

https://reviews.llvm.org/D64488



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

[PATCH] D56650: [lld] [ELF] Support customizing behavior on target triple

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

> Personally I am opposed to this change. The compiler driver (gcc,clang) has a 
> set of arch/OS dependent defaults. It seems weird/redundant to add another 
> sets of defaults on the linker side.

The NetBSD toolchain relies on internal knowledge in a linker that can be used 
as a standalone program. This is our design choice and this was decided 
internally to be kept. You might not be nice from some point of view, but it is 
our real-world use-case, we wrote set of patches for it, we maintain a buildbot 
building and running lld tests... we try to upstream it.

A similar customization is actually done for (at least) Darwin (as the only OS 
using MachO) and FreeBSD (by an accident it's possible to differentiate FreeBSD 
on emul name). Please see that Darwin appends default paths (last time I 
checked) and for FreeBSD there are some fixups based on detecting FreeBSD. For 
OpenBSD there is an accident that it works thanks to embedding 'openbsd' in 
customization parts. For NetBSD we don't have such escape detection viable to 
include fixups and we shall detect triple target based on lld executable name.

If you don't like to see this code by defaut in lld, we can include it under 
`#ifdef` or overload the 'elf' namespace into 'netbsdelf'.

We need to unearth from our local patches and get upstream version of lld 
functional.


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

https://reviews.llvm.org/D56650



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

[PATCH] D56650: [lld] [ELF] Support customizing behavior on target triple

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.
Herald added a subscriber: MaskRay.

@ruiu ping?

LLVM 9 is branching soon and we would like to unearth from local patches.

From the internal discussions it was decided that we want to maintain our 
current behavior that differs to Linux.


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

https://reviews.llvm.org/D56650



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

[PATCH] D59744: Fix i386 ABI "__m64" type bug

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D59744#1529218 , @mgorny wrote:

> In D59744#1529182 , @krytarowski 
> wrote:
>
> > In D59744#1527412 , @wxiao3 wrote:
> >
> > > Consider other Systems (e.g Darwin, PS4 and FreeBSD) don't want to spend 
> > > any effort dealing with the ramifications of ABI breaks (as discussed in 
> > > https://reviews.llvm.org/D60748) at present, I only fix the bug for 
> > > Linux. If other system wants the fix, the only thing needed is to add a 
> > > flag (like "IsLinuxABI" ) to enable it.
> >
> >
> > CC @mgorny and @joerg - do we want this for NetBSD?
>
>
> Probably yes. FWICS, gcc uses `%mm0` and `%mm1` on NetBSD while clang doesn't.


Unless Joerg will protest, @wxiao3 please enable it on NetBSD as well.. but 
personally I would enable it unconditionally for all sysv ABIs.


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

https://reviews.llvm.org/D59744



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

[PATCH] D59744: Fix i386 ABI "__m64" type bug

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added subscribers: mgorny, joerg.
krytarowski added a comment.

In D59744#1527412 , @wxiao3 wrote:

> Consider other Systems (e.g Darwin, PS4 and FreeBSD) don't want to spend any 
> effort dealing with the ramifications of ABI breaks (as discussed in 
> https://reviews.llvm.org/D60748) at present, I only fix the bug for Linux. If 
> other system wants the fix, the only thing needed is to add a flag (like 
> "IsLinuxABI" ) to enable it.


CC @mgorny and @joerg - do we want this for NetBSD?


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

https://reviews.llvm.org/D59744



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

[PATCH] D62638: [analyzer] A Python script to prettify the ExplodedGraph dumps.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This commit breaks the NetBSD buildbot node.

http://lab.llvm.org:8011/builders/netbsd-amd64/builds/20359

The problem is that this patch hardcodes python specific binary name, while it 
has to be detected dynamically or ideally passed from CMake. Afair lit has a 
knowledge of too.

`​#!/usr/bin/env python` # <- unportable form

On NetBSD with pkgsrc this can be python2.7, but the name is not fixed.

Plase correct this.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62638



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

[PATCH] D59744: Fix i386 ABI "__m64" type bug

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

sysv abi is not only for UNIX but most non-Windows ones (BSDs, HAIKU, ...).


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

https://reviews.llvm.org/D59744



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

[PATCH] D60748: Fix i386 struct and union parameter alignment

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added subscribers: mgorny, joerg.
krytarowski added inline comments.



Comment at: lib/CodeGen/TargetInfo.cpp:1501
+//
+// Exclude other System V OS (e.g Darwin, PS4 and FreeBSD) since we don't
+// want to spend any effort dealing with the ramifications of ABI breaks.

Darwin and BSD are not System V.

CC: @joerg @mgorny for NetBSD. Do we need to do something here?


Repository:
  rC Clang

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

https://reviews.llvm.org/D60748



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

[PATCH] D62005: [libunwind] [test] Fix inferring source paths

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski resigned from this revision.
krytarowski added a comment.
Herald added a subscriber: krytarowski.

It is probably fine.. but I will defer review to lit/libc++ maintainers.


Repository:
  rUNW libunwind

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

https://reviews.llvm.org/D62005



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

[PATCH] D60728: [clang] [test] Add a (xfailing) test for PR41027

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D60728#1469794 , @hans wrote:

> In D60728#1468713 , @krytarowski 
> wrote:
>
> > In D60728#1468486 , @hans wrote:
> >
> > > What's the value in checking in this xfail'ed test without an actual fix 
> > > for the problem?
> >
> >
> > Raise awareness about the problem.
>
>
> I don't think that works. No one is reading through the test files of the 
> repository.


Well, I think we should treat it from the other side around.

Could we please revert it and backport revert to 8.0.1? The author(s) can 
improve the implementation and get this pr41027 test to check if a new version 
works.

Right now this blocks upgrades on NetBSD as a number of CPUs is affected (but 
not x86, so it was overlooked before 8.0 by others than @joerg).


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

https://reviews.llvm.org/D60728



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

[PATCH] D60728: [clang] [test] Add a (xfailing) test for PR41027

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D60728#1468486 , @hans wrote:

> What's the value in checking in this xfail'ed test without an actual fix for 
> the problem?


Raise awareness about the problem.


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

https://reviews.llvm.org/D60728



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

[PATCH] D60728: [clang] [test] Add a (xfailing) test for PR41027

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a reviewer: void.
krytarowski added a subscriber: void.
krytarowski added a comment.

Adding @void, regression introduced with D55616 
.


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

https://reviews.llvm.org/D60728



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

[PATCH] D55616: Emit ASM input in a constant context

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@void hi, this broke assembly code on NetBSD for various archs and blocks 
upgrade of the toolchain.

Could you please have a look? https://bugs.llvm.org/show_bug.cgi?id=41027


Repository:
  rC Clang

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

https://reviews.llvm.org/D55616



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

[PATCH] D52610: [Esan] Port cache frag to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski resigned from this revision.
krytarowski added a comment.
Herald added a project: clang.

ESan is now discontinued.


Repository:
  rC Clang

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

https://reviews.llvm.org/D52610



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

[PATCH] D56647: [WIP] [ELF] Implement --copy-dt-needed-entries

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

NetBSD patches GNU linker to behave in the original way. This behavior is 
mandated from lld as well in order to treat it as a drop-in replacement.

Preference here and of other lld characteristics is so strong that the NetBSD 
community in case of rejected patches will continue to maintain downstream 
patches.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56647



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

[PATCH] D56647: [WIP] [ELF] Implement --copy-dt-needed-entries

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: LLVM.

@ruiu ping?


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56647



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

[PATCH] D58592: [clang] [ToolChains/NetBSD] Support relative libc++ header path

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski accepted this revision.
krytarowski added a comment.
This revision is now accepted and ready to land.

This will make life much more easier now with this change.


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

https://reviews.llvm.org/D58592



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

[PATCH] D58592: [clang] [ToolChains/NetBSD] Support relative libc++ header path

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: clang/lib/Driver/ToolChains/NetBSD.cpp:430
+// system install from src
+getDriver().SysRoot + "/usr/include/c++",
+  };

mgorny wrote:
> krytarowski wrote:
> > mgorny wrote:
> > > krytarowski wrote:
> > > > I propose to go for:
> > > > 
> > > > `getDriver().SysRoot + "/usr/include/c++/v1",` with a fallback for 
> > > > `getDriver().SysRoot + "/usr/include/c++",`
> > > > 
> > > > This innocent customization of paths triggers a lot of headache.
> > > > 
> > > > We should switch system location to `/usr/include/c++/v1` for next 
> > > > version of LLVM (9.0 as 8.0 is branched and will be released soon).
> > > > 
> > > > This way we will keep compat with legacy paths and new clang.
> > > This is already handled by the relative path (when `getDriver().Dir` is 
> > > `/usr/bin`).
> > We still can build newer Clang in pkgsrc on newer base with headers moved 
> > to `/usr/include/v1/c++` and it will break.
> I don't understand. Why would it break? (besides the typo in the path)
clang will be installed into `/usr/pkg/bin/clang` and we want to reach the 
default headers in `/usr/include/c++/v1` (in a setup without installing libc++ 
in pkgsrc)


Repository:
  rC Clang

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

https://reviews.llvm.org/D58592



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

[PATCH] D58592: [clang] [ToolChains/NetBSD] Support relative libc++ header path

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: clang/lib/Driver/ToolChains/NetBSD.cpp:430
+// system install from src
+getDriver().SysRoot + "/usr/include/c++",
+  };

mgorny wrote:
> krytarowski wrote:
> > I propose to go for:
> > 
> > `getDriver().SysRoot + "/usr/include/c++/v1",` with a fallback for 
> > `getDriver().SysRoot + "/usr/include/c++",`
> > 
> > This innocent customization of paths triggers a lot of headache.
> > 
> > We should switch system location to `/usr/include/c++/v1` for next version 
> > of LLVM (9.0 as 8.0 is branched and will be released soon).
> > 
> > This way we will keep compat with legacy paths and new clang.
> This is already handled by the relative path (when `getDriver().Dir` is 
> `/usr/bin`).
We still can build newer Clang in pkgsrc on newer base with headers moved to 
`/usr/include/v1/c++` and it will break.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58592



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

[PATCH] D58592: [clang] [ToolChains/NetBSD] Support relative libc++ header path

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: clang/lib/Driver/ToolChains/NetBSD.cpp:430
+// system install from src
+getDriver().SysRoot + "/usr/include/c++",
+  };

I propose to go for:

`getDriver().SysRoot + "/usr/include/c++/v1",` with a fallback for 
`getDriver().SysRoot + "/usr/include/c++",`

This innocent customization of paths triggers a lot of headache.

We should switch system location to `/usr/include/c++/v1` for next version of 
LLVM (9.0 as 8.0 is branched and will be released soon).

This way we will keep compat with legacy paths and new clang.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58592



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

[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

The NetBSD buildbot breaks in these tests now:

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8/builds/18721

Both tests break in a similar way:

  Command Output (stderr):
  --
  + : 'RUN: at line 1'
  + not /home/motus/netbsd8/netbsd8/build/bin/clang -cc1 -internal-isystem 
/home/motus/netbsd8/netbsd8/build/lib/clang/9.0.0/include -nostdsysteminc 
-emit-llvm -o 
/home/motus/netbsd8/netbsd8/build/tools/clang/test/Frontend/Output/output-failures.c.tmp/doesnotexist/somename
 /home/motus/netbsd8/netbsd8/llvm/tools/clang/test/Frontend/output-failures.c
  + : 'RUN: at line 2'
  + /home/motus/netbsd8/netbsd8/build/bin/FileCheck -check-prefix=OUTPUTFAIL 
-input-file=/home/motus/netbsd8/netbsd8/build/tools/clang/test/Frontend/Output/output-failures.c.tmp
 /home/motus/netbsd8/netbsd8/llvm/tools/clang/test/Frontend/output-failures.c
  
/home/motus/netbsd8/netbsd8/llvm/tools/clang/test/Frontend/output-failures.c:4:16:
 error: OUTPUTFAIL: expected string not found in input
  // OUTPUTFAIL: error: unable to open output file 
'{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'
 ^
  
/home/motus/netbsd8/netbsd8/build/tools/clang/test/Frontend/Output/output-failures.c.tmp:1:1:
 note: scanning from here
  error: unable to open output file 
'/home/motus/netbsd8/netbsd8/build/tools/clang/test/Frontend/Output/output-failures.c.tmp/doesnotexist/somename':
 'Not a directory'
  ^
  
/home/motus/netbsd8/netbsd8/build/tools/clang/test/Frontend/Output/output-failures.c.tmp:1:86:
 note: possible intended match here
  error: unable to open output file 
'/home/motus/netbsd8/netbsd8/build/tools/clang/test/Frontend/Output/output-failures.c.tmp/doesnotexist/somename':
 'Not a directory'

   ^
  
  --

Please fix.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57592



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

[PATCH] D56650: [lld] [ELF] Support customizing behavior on target triple

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

> chandlerc added a comment.
> 
> There was a long discussion between two NetBSD maintainers about this (both 
> already in the reviewers list of this patch). I'm not sure if there is an 
> existing thread that would be better to follow up on as opposed to starting a 
> fresh thread.

The discussion is ongoing since 2017 and we have an impasse.

> I think the question was: should the path search logic be handled in the 
> `clang` driver or in LLD itself. FWIW, I prefer that NetBSD follow the same 
> design as every other platform here with the (somewhat C and C++ specific) 
> search logic provided by the `clang` driver.

Path logic is unfortunately just the tip of iceberg of customization we need, 
but it's true that its the first problem to encounter when attempting to use 
lld/NetBSD. Depending on the approach of solving it we can follow up with other 
changes.


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

https://reviews.llvm.org/D56650



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

[PATCH] D56650: [lld] [ELF] Support customizing behavior on target triple

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56650#1377546 , @ruiu wrote:

> If you still need to patch GNU ld, it doesn't seems like this patch makes 
> things easier for you. (But even if this would make it easier for you, this 
> patch's approach is not okay by design though.)


If we can get standalone lld functional out of the box and respecting target, 
we no longer need to patch GCC/LD/distribution/3rd-party-software.

If there is a strong feeling to retain lld ELF target as it is, we can grow a 
custom target like Darwin/Windows and specify customization there. The 
mentioned Darwin adds /usr/lib in the linker directly.  We need analogous 
opportunity on our end.


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

https://reviews.llvm.org/D56650



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

[PATCH] D56650: [lld] [ELF] Support customizing behavior on target triple

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

If we pass flags from clang, we sacrifice:

- lld usable as a standalone executable
- gcc capable to use lld as a functional linker
- clang driver not capable to call unpatched gnu ld/gold as we grow local flags 
to workaroud the customization (such as -z nognustack)
- compat with a number of programs programs that call linker directly and we 
customize the passed flags (gcc itself is one of them)

We just gain clang+lld tandem to work and we must retain GCC/LD 
interoperability (which as I understand isn't a priority/interesting for other 
OSes).

In theory we can patch:

- GCC to pass lld flags
- GNU LD (/gold) to accept new flags
- all the programs using linker to stop doing so (like the GCC project)

We need to tune in lld at least for start (out of my head, likely not a 
finished list):

- tune the DT_NEEDED behavior,
- rpath behavior,
- GNU stack generation
- specify default target/emulation search paths
- disable 3 segments (disable ro one)

We can address all the issues either in lld or in all the other projects around 
which certainly doesn't scale (and I expect in particular problems to push e.g. 
-z nognustack to GNU ld(1)).

OpenBSD indeed patches downstream their linkers for additional flags and 
accidentally it works better in the lld design. In NetBSD we struggle to get 
sane defaults rather than a set of additional flags. GNU stack is unwanted also 
on at least OpenBSD(/Fuchsia..) and there is no way to disable it in lld as of 
now (a proposal is to grow a custom flag). All OSes need to pass default paths 
for standalone linker usage (I've listed a dozen of examples from FreeBSD ports 
in other review).

The current feeling in the project is that if we cannot set the defaults we 
should fork the lld driver downstream and patch it there, which is a lose as 
the upstream version will keep to be unusable.


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

https://reviews.llvm.org/D56650



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

[PATCH] D56650: [lld] [ELF] Support customizing behavior on target triple

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@rui we need some resolution here. We have stronger feelings from the community 
to customize the linker directly based on detected triple.

At least other !GNU platforms will benefit from it too (at least FreeBSD, 
OpenBSD and other BSD derivations like mentioned CheriBSD).
FreeBSD already adds such target customization based on an emulation name hack, 
we cannot repeat it on NetBSD in the same way.

In the worst case we can even produce a new flavor of lld target that 
resembles/duplicates original ELF and targets (Net)BSD.

Under what circumstances and what model will you let to support this approach?

It does allow us better customization with keeping compat with other toolchain 
components, especially from the the GNU world.

Ideally we would get something for LLVM 8.0.. as it could be still backportable 
at least for downstream purposes. RC2 is planned for Feburary 6th and we need 
unpatched lld functional out of the box.


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

https://reviews.llvm.org/D56650



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

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

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D57303#1373077 , @phosek wrote:

> In D57303#1373061 , @krytarowski 
> wrote:
>
> > How do you resolve paths? Linker cache with registry of libraries?
>
>
> `DT_NEEDED` aren't treated as paths, they are used as object names (keys); 
> dynamic linker passes those to the loader service which is responsible for 
> resolving them and returning back the corresponding memory objects.


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


Repository:
  rC Clang

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

https://reviews.llvm.org/D57303



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

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

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D57303#1373057 , @phosek wrote:

> In D57303#1373035 , @krytarowski 
> wrote:
>
> > + vitalybuka
> >
> > Can we fix it for everybody? It's certainly not restricted to NetBSD.
>
>
> As a point of reference, we use shared runtimes on Fuchsia but we don't use 
> rpath so this is not something we want for every system.


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


Repository:
  rC Clang

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

https://reviews.llvm.org/D57303



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

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

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a reviewer: vitalybuka.
krytarowski added a comment.

+ vitalybuka

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


Repository:
  rC Clang

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

https://reviews.llvm.org/D57303



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56554#1354885 , @ruiu wrote:

> In D56554#1353572 , @krytarowski 
> wrote:
>
> > What do you think about this new logic:
> >
> > 1. specified `-z execstack` -> do not emit GNU STACK segment
> > 2. specified `-z noexecstack` -> emit GNU STACK segment
> > 3. no option specified -> detect `findSection(".note.GNU-stack")` (I might 
> > miss offhand some details here to be sure if it is reliable) 3.1. detected 
> > -> emit GNU STACK segment 3.2. not detected -> do not emit GNU STACK segment
> >
> >   Additionally we will specify explicitly in the clang driver for Linux and 
> > FreeBSD `-z noexecstack`.
>
>
> I think I don't like the very idea of using "marker sections" in input object 
> files to change the linker behavior. That's too subtle and seems error-prone 
> to me.
>
> After thinking for a while, I started thinking that the first version of this 
> patch is probably exactly what we want. I had been thinking that `-z 
> {no,}execstack` and `-z {no,}gnustack` are four different options, but what 
> we actually want to get is tri-state:
>
> - emit PT_GNU_STACK with RWX permission
> - emit PT_GNU_STACK with RW permission
> - do not emit PT_GNU_STACK
>
>   So we could map them to `-z {execstack,noexecstack,nognustack}`, 
> respectively, with default set to `-z noexecstack`. You guys can pass `-z 
> nognustack` to the linker to tell the linker to not emit it at all. That's 
> exactly this patch does.


Actually after a longer thought, I recommend to hardcode inside lld a check for 
`TargetTriple.isOSNetBSD()`. Using `-z nognustack` isn't portable to other 
linkers.




Comment at: ELF/Writer.cpp:1979
 
-  // PT_GNU_STACK is a special section to tell the loader to make the
-  // pages for the stack non-executable. If you really want an executable
-  // stack, you can pass -z execstack, but that's not recommended for
-  // security reasons.
-  unsigned Perm = PF_R | PF_W;
-  if (Config->ZExecstack)
-Perm |= PF_X;
-  AddHdr(PT_GNU_STACK, Perm)->p_memsz = Config->ZStackSize;
+  if (!Config->ZNognustack) {
+// PT_GNU_STACK is a special section to tell the loader to make the

Please go for `if (!Config->TargetTriple.isOSNetBSD()) {`


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



___
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

[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] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@ruiu actually if we can get D56215  merged we 
will be able to tune it specifically for NetBSD (with `if 
(Config->TargetTriple.isOSNetBSD()) {`) and retain intact the current 
Linux-biased logic for everybody who deserves to use it.

We will need to add similar NetBSD adjustments in other parts of lld.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



___
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] D56607: [clang] [NetBSD] Enable additional sanitizer types

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Please check these options in regression test-suite. There are also some 
missing entries and please add them too.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56607



___
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] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

What do you think about this new logic:

1. specified `-z execstack` -> do not emit GNU STACK segment
2. specified `-z noexecstack` -> emit GNU STACK segment
3. no option specified -> detect `findSection(".note.GNU-stack")` (I might miss 
offhand some details here to be sure if it is reliable)

3.1. detected -> emit GNU STACK segment
3.2. not detected -> do not emit GNU STACK segment

Additionally we will specify explicitly in the clang driver for Linux and 
FreeBSD `-z noexecstack`.

If this is not acceptable and we must use GNU extensions for everybody, we will 
need to specify this ugly `-z noexecstack` in the NetBSD driver (once we will 
get an agreement that we customize the linker through the driver).


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I understand the concerns, but lld is biased with being a Linux linker. We need 
to customize it (restore defaults?) for NetBSD.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Shouldn't the logic of emitting/not-emitting be based on 
`findSection(".note.GNU-stack")`? @mgorny can you please investigate it?


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Actually looking at GNU ld(1) source code, the logic is a little bit more 
complex and it depends on more aspects like relocations.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56554#1353513 , @ruiu wrote:

> In D56554#1353487 , @krytarowski 
> wrote:
>
> > In D56554#1353368 , @ruiu wrote:
> >
> > > The absence of PT_GNU_STACK segment makes stack area executable on 
> > > systems that recognizes PT_GNU_STACK segment. So, I think if `-z 
> > > execstack` is specified, we should omit PT_GNU_STACK segment rather than 
> > > adding it, which I think you guys want. If we do that, it seems `-z 
> > > nognustack` is a redundant option. That option name is unfortunate (you 
> > > don't really mean you want an executable stack area), but that's I think 
> > > still better than adding an option that is very similar to an existing 
> > > feature.
> >
> >
> > If we are going to change the meaning of `-z execstack`, can we rename the 
> > option in lld? Probably to `-z gnustack` vs `-z nognustack`, probably there 
> > is no other use-case than RWX->RW protection change.
>
>
> Both `-z execstack` and `-z noexecstack` are supported by GNU linkers, so we 
> can't simply rename them. We might be able to define aliases to the options. 
> But I'm not sure if we want it if the only reason to do so is aesthetic 
> reason.


For compat with GNU linkers we could disable it by default, and emit GNU stack 
only on demand.

The current approach to enable GNU STACK is to inline a new segment definition 
in assembly. It's done this way in llvm projects too.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56554#1353368 , @ruiu wrote:

> The absence of PT_GNU_STACK segment makes stack area executable on systems 
> that recognizes PT_GNU_STACK segment. So, I think if `-z execstack` is 
> specified, we should omit PT_GNU_STACK segment rather than adding it, which I 
> think you guys want. If we do that, it seems `-z nognustack` is a redundant 
> option. That option name is unfortunate (you don't really mean you want an 
> executable stack area), but that's I think still better than adding an option 
> that is very similar to an existing feature.


If we are going to change the meaning of `-z execstack`, can we rename the 
option in lld? Probably to `-z gnustack` vs `-z nognustack`, probably there is 
no other use-case than RWX->RW protection change.

Systems like fuchsia don't need/want it either. FreeBSD recognize this  
ELF segment.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Driver.cpp:874
   Config->ZGlobal = hasZOption(Args, "global");
+  Config->ZNognustack = hasZOption(Args, "nognustack");
   Config->ZHazardplt = hasZOption(Args, "hazardplt");

I would add `gnustack` vs `nognustack` - two options, but it's up to 
maintainers to decide. We can keep it enabled by default and disable it in 
NetBSD's clang driver.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: ELF/Writer.cpp:1980
+  if (!Config->ZNognustack) {
+// PT_GNU_STACK is a special section to tell the loader to make the
+// pages for the stack non-executable. If you really want an executable

section -> segment?



Comment at: docs/ld.lld.1:515
+.Dv PT_GNU_STACK
+segment.
 .It Cm norelro

mgorny wrote:
> krytarowski wrote:
> > section?
> I think 'segment' is actually the correct term here.
I see, probably right.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Looks good, we don't GNU STACK on NetBSD.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



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

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: docs/ld.lld.1:515
+.Dv PT_GNU_STACK
+segment.
 .It Cm norelro

section?


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56554



___
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

[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

[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] D56288: [ELF] Do not enable 'new dtags' on NetBSD by default

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

On NetBSD the 'new' semantics was already implemented with 'old' RPATH. I don't 
know the timing whether there already existed RUNPATH, but the result is that 
we never implemented it and never needed it.  The core of NetBSD was convinced 
to add an alias as it was very difficult in some examples (probably due to 
Rust) to rollback to 'old' RPATH.

I don't have any complains against lld developers, the only ones are against 
the NetBSD community that we are forced to be out of the lld development. It 
would be addressed already long time and probably RUNPATH wouldn't be leaked 
into executables shipped to NetBSD in the first place... it's counter-effective 
attitude to be in opposition to use lld on philosophical principle.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56288



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

[PATCH] D56288: [ELF] Do not enable 'new dtags' on NetBSD by default

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D56288#1348148 , @mgorny wrote:

> Ok, maybe I'm being silly but since clang driver has to pass 
> `--enable-new-dtags` for GNU ld compatibility anyway, wouldn't it make sense 
> to keep the default as disabled in order to match GNU ld behavior?


This would be the best especially in the context of philosophical issues of 
builtin knowledge in LLD and difficulty to resolve it.

Most Linux software doesn't need RPATH/RUNPATH as there is ld-config.. but it's 
completely the opposite on NetBSD where almost everything needs proper RPATH 
setting due to lack of Linux style ld-config.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56288



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

[PATCH] D52610: [Esan] Port cache frag to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Can you try to port this mutant thread-process in ESan to FreeBSD? I don't want 
to see changes in generic LLVM code.


Repository:
  rC Clang

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

https://reviews.llvm.org/D52610



___
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

[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

[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

[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

[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 +0000, 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

[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

[PATCH] D56288: [ELF] Do not enable 'new dtags' on NetBSD by default

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

We want to keep it disabled by default on NetBSD.. but it would be to keep 
dynamic detection of target NetBSD rather than hardcoded ifdef.

GNU ld sets it by default to false, following it would be the easiest option.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56288



___
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 +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':

  # 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

[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

[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

[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

[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