[PATCH] D50413: [libunwind][include] Add some missing definitions to .

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

NetBSD uses `typedef void *_Unwind_Ptr;` unconditionally in its ``... 
if that has to be matched.

Additionally: `typedef long _Unwind_Word;`.


Repository:
  rUNW libunwind

https://reviews.llvm.org/D50413



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

[PATCH] D50413: [libunwind][include] Add some missing definitions to .

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a subscriber: joerg.
krytarowski added a comment.

In https://reviews.llvm.org/D50413#1192475, @cdavis5x wrote:

> In https://reviews.llvm.org/D50413#1191726, @krytarowski wrote:
>
> > NetBSD uses `typedef void *_Unwind_Ptr;` unconditionally in its 
> > ``... if that has to be matched.
>
>
> Done.
>
> > Additionally: `typedef long _Unwind_Word;`.
>
> Done.


I recommend to get a review of this by @joerg


Repository:
  rUNW libunwind

https://reviews.llvm.org/D50413



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

[PATCH] D50413: [libunwind][include] Add some missing definitions to .

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

From my point of view, the number of people who have idea about these types and 
why do they differ between ABIs and OSes is so low, that it's even hard to get 
someone to review it here.


Repository:
  rUNW libunwind

https://reviews.llvm.org/D50413



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

[PATCH] D47814: Teach libc++ to use native NetBSD's max_align_t

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

If there are no more comments, I will land this by the end of this week.


Repository:
  rL LLVM

https://reviews.llvm.org/D47814



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

[PATCH] D47814: Teach libc++ to use native NetBSD's max_align_t

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

@chandlerc thank you for your note. I've originally treated this change as an 
obvious code change, just the reviewers regardless of reviewing an analogous 
change for MUSL, had no interest in NetBSD.


Repository:
  rL LLVM

https://reviews.llvm.org/D47814



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

[PATCH] D38900: libunwind: document tested FreeBSD configs and sort OS list

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a subscriber: joerg.
krytarowski added a comment.

@joerg might have insight on ppc, sparc64, arm on NetBSD.


https://reviews.llvm.org/D38900



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

[PATCH] D39162: [test] Fix clang-test for FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: test/Unit/lit.cfg.py:39
 shlibpath_var = ''
-if platform.system() == 'Linux':
+if platform.system() in ['Linux', 'FreeBSD']:
 shlibpath_var = 'LD_LIBRARY_PATH'

Please include 'NetBSD' next to 'FreeBSD'.


https://reviews.llvm.org/D39162



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

[PATCH] D39162: [test] Fix clang-test for FreeBSD and NetBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D39162#903186, @joerg wrote:

> I think we should special case Darwin and Windows and fall-back to 
> LD_LIBRARY_PATH for the rest. Can't remember if there is a UNIX-like platform 
> left where it doesn't work.


SHLIB_PATH in HP/UX


https://reviews.llvm.org/D39162



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

[PATCH] D39162: [test] Fix clang-test for FreeBSD and NetBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D39162#903190, @krytarowski wrote:

> In https://reviews.llvm.org/D39162#903186, @joerg wrote:
>
> > I think we should special case Darwin and Windows and fall-back to 
> > LD_LIBRARY_PATH for the rest. Can't remember if there is a UNIX-like 
> > platform left where it doesn't work.
>
>
> SHLIB_PATH in HP/UX


Hmm SHLIB_PATH has been marked as legacy and they probably switched to 
LD_LIBRARY_PATH.

AIX might still ship with LIBPATH.

I agree that adding defines for OS'es that are barely developed (especially 
closed-source) without LLVM developers might be accumulating unused code.


https://reviews.llvm.org/D39162



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

[PATCH] D49788: [Docs] Update supported oses for ubsan, asan and msan

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Please include NetBSD in UBSan. Also please drop the list of supported 
architectures or rephrase it. It works on e.g. NetBSD/vax.


Repository:
  rC Clang

https://reviews.llvm.org/D49788



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

[PATCH] D49788: [Docs] Update supported oses for ubsan, asan and msan

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Please update the documentation of ThreadSanitizer.rst and include at least 
NetBSD/amd64.


Repository:
  rC Clang

https://reviews.llvm.org/D49788



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

[PATCH] D49788: [Docs] Update supported oses for ubsan, asan and msan

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In SafeStack.rst +NetBSD.


Repository:
  rC Clang

https://reviews.llvm.org/D49788



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

[PATCH] D49788: [Docs] Update supported oses for ubsan, asan and msan

[Kamil Rytarowski via Phabricator via cfe-commits]

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

Please improve the commit description and reflect with reality.


https://reviews.llvm.org/D49788



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

[PATCH] D43279: Add Xray instrumentation compile-time/link-time support to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: FreeBSD.cpp:139
+  CmdArgs.push_back("--no-as-needed");
+  CmdArgs.push_back("-lpthread");
+  CmdArgs.push_back("-lrt");

`-pthread`?


Repository:
  rC Clang

https://reviews.llvm.org/D43279



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

[PATCH] D43279: Add Xray instrumentation compile-time/link-time support to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: FreeBSD.cpp:139
+  CmdArgs.push_back("--no-as-needed");
+  CmdArgs.push_back("-lpthread");
+  CmdArgs.push_back("-lrt");

devnexen wrote:
> krytarowski wrote:
> > `-pthread`?
> Did not seem needed maybe it s different for NetBSD ?
```
   -pthread
   Adds support for multithreading with the pthreads library.  This
   option sets flags for both the preprocessor and linker.
```

From gcc(1). `-lpthread` looks like an alias, but `-pthread` is preferred. A 
system library does not need to be called `libpthread.so` or so, and it's not 
named this way on FreeBSD.


Repository:
  rC Clang

https://reviews.llvm.org/D43279



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

[PATCH] D43279: Add Xray instrumentation compile-time/link-time support to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

It looks good to me, I can land this for you.


https://reviews.llvm.org/D43279



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

[PATCH] D43148: Adding msan support for FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: FreeBSD.cpp:397
 Res |= SanitizerKind::FuzzerNoLink;
+if (IsX86_64)
+Res |= SanitizerKind::Memory;

I would keep it in a dedicated `if (IsX86_64)` (similar to NetBSD). Otherwise 
it looks fine.


Repository:
  rC Clang

https://reviews.llvm.org/D43148



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I was wrong about `-pthread` here, as we pass it directly to a linker. ld(1) 
accepts `-lpthread` not `-pthread`. cc(1) requires `-pthread` as it defines 
additional flags like `_REENTRANT` (OS-specific).


https://reviews.llvm.org/D43378



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/XRayArgs.cpp:56
+<< (std::string(XRayInstrumentOption) + " only on "
+"FreeBSD x86_64");
+}

I think it's better to not hardcode `x86_64` here in a message, we will need 
change it with new CPUs.



Comment at: lib/Driver/XRayArgs.cpp:60
   D.Diag(diag::err_drv_clang_unsupported)
   << (std::string(XRayInstrumentOption) + " on non-Linux target OS");
 XRayInstrument = true;

Please make this message generic - replace `non-Linux` target with a better 
wording.


https://reviews.llvm.org/D43378



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/XRayArgs.cpp:56
+<< (std::string(XRayInstrumentOption) + " only on "
+"FreeBSD x86_64");
+}

krytarowski wrote:
> I think it's better to not hardcode `x86_64` here in a message, we will need 
> change it with new CPUs.
I think we can reuse the existing above code here as well:

`<< (std::string(XRayInstrumentOption) + " on " + Triple.str());`



Comment at: lib/Driver/XRayArgs.cpp:58
+}
+} else
   D.Diag(diag::err_drv_clang_unsupported)

Is this a correct style of `} else` without `{`?

I recommend to use `git-clang-format` to make sure.


https://reviews.llvm.org/D43378



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Please add a clang test to verify that we can pass xray flags, as requested by 
@dberris.


https://reviews.llvm.org/D43378



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/XRayArgs.cpp:54
+if (Triple.getArch() != llvm::Triple::x86_64) {
+  D.Diag(diag::err_drv_clang_unsupported)
+  << (std::string(XRayInstrumentOption) + " on " + Triple.str());

Missing:

```
break;
default:
```


https://reviews.llvm.org/D43378



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/XRayArgs.cpp:54
+if (Triple.getArch() != llvm::Triple::x86_64) {
+  D.Diag(diag::err_drv_clang_unsupported)
+  << (std::string(XRayInstrumentOption) + " on " + Triple.str());

devnexen wrote:
> krytarowski wrote:
> > Missing:
> > 
> > ```
> > break;
> > default:
> > ```
> It s a simple if above
Ah, right!.


https://reviews.llvm.org/D43378



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

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: cfe/trunk/test/Driver/XRay/xray-shared-noxray.cpp:11
 //
-// REQUIRES: linux, enable_shared
+// REQUIRES: enable_shared
 int foo() { return 42; }

```
FAIL: Clang :: Driver/XRay/xray-shared-noxray.cpp (6820 of 38122)
 TEST 'Clang :: Driver/XRay/xray-shared-noxray.cpp' FAILED 

Script:
--
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang
 --driver-mode=g++ -shared -o /dev/null -v -fxray-instrument 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp
 -###
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang
 --driver-mode=g++ -shared -o /dev/null -v -fxray-instrument 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp
 -### 2>&1 |  
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/FileCheck
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp
 --check-prefix=SHARED
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang
 --driver-mode=g++ -static -o /dev/null -v -fxray-instrument 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp
 -### -DMAIN
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang
 --driver-mode=g++ -static -o /dev/null -v -fxray-instrument 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp
 -### 2>&1 -DMAIN  | 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/FileCheck
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp
 --check-prefix=STATIC
--
Exit Code: 1

Command Output (stderr):
--
clang version 7.0.0 (trunk 325746)
Target: x86_64-scei-ps4
Thread model: posix
InstalledDir: 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin
clang-7.0: error: the clang compiler does not support '-fxray-instrument on 
non-supported target OS'
 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-7.0"
 "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all" "-disable-free" 
"-main-file-name" "xray-shared-noxray.cpp" "-mrelocation-model" "pic" 
"-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" 
"-mconstructor-aliases" "-munwind-tables" "-target-cpu" "btver2" 
"-debugger-tuning=sce" "-backend-option" "-generate-arange-section" 
"-debug-forward-template-params" "-dwarf-explicit-import" 
"-momit-leaf-frame-pointer" "-v" "-resource-dir" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/lib/clang/7.0.0"
 "-fdeprecated-macro" "-fdebug-compilation-dir" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver/XRay"
 "-fstack-size-section" "-ferror-limit" "19" "-fmessage-length" "0" 
"-fxray-instrument" "-fxray-instruction-threshold=200" "-stack-protector" "2" 
"-fno-rtti" "-fdeclspec" "-fobjc-runtime=gnustep" "-fdiagnostics-show-option" 
"-o" "/tmp/lit_tmp_uoU38D/xray-shared-noxray-3e3746.o" "-x" "c++" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/XRay/xray-shared-noxray.cpp"
 "orbis-ld" "--eh-frame-hdr" "-Bshareable" "--enable-new-dtags" "-o" 
"/dev/null" "crti.o" "crtbeginS.o" 
"/tmp/lit_tmp_uoU38D/xray-shared-noxray-3e3746.o" "-lkernel" "-lstdc++" "-lm" 
"-lcompiler_rt" "--as-needed" "-lstdc++" "--no-as-needed" "-lc" "-lcompiler_rt" 
"--as-needed" "-lstdc++" "--no-as-needed" "crtendS.o" "crtn.o"
clang-7.0: error: unsupported option '-static' for target 'PS4'
clang version 7.0.0 (trunk 325746)
Target: x86_64-scei-ps4
Thread model: posix
InstalledDir: 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin
clang-7.0: error: the clang compiler does not support '-fxray-instrument on 
non-supported target OS'
 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-7.0"
 "-cc1" "-triple" "x86_64-scei-ps4" "-emit-obj" "-mrelax-all" "-disable-free" 
"-main-file-name" "xray-shared-noxray.cpp" "-static-define" 
"-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" 
"-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" 
"-target-cpu" "btver2" "-debugger-tuning=sce" "-backend-option" 
"-generate-arange-section" "-debug-forward-template-params" 
"-dwarf-explicit-import

[PATCH] D43378: FreeBSD driver / Xray flags moving pthread to compile flags.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: cfe/trunk/test/Driver/XRay/xray-instrument-os.c:2
 // RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
-// XFAIL: -linux-
 // REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64

```
 TEST 'Clang :: Driver/XRay/xray-instrument-os.c' FAILED 

Script:
--
not /home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/bin/clang -o 
/dev/null -v -fxray-instrument -c 
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/test/Driver/XRay/xray-instrument-os.c
--
Exit Code: 1

Command Output (stderr):
--
clang version 7.0.0 (trunk 325746)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8.0.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/bin/clang-7.0" 
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free 
-main-file-name xray-instrument-os.c -mrelocation-model static -mthread-model 
posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases 
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info 
-debugger-tuning=gdb -v -coverage-notes-file /dev/null.gcno -resource-dir 
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/lib/clang/7.0.0 
-internal-isystem /usr/local/include -internal-isystem 
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/lib/clang/7.0.0/include
 -internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-fdebug-compilation-dir 
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/tools/clang/test/Driver/XRay
 -ferror-limit 19 -fmessage-length 0 -fxray-instrument 
-fxray-instruction-threshold=200 -fobjc-runtime=gcc -fdiagnostics-show-option 
-o /dev/null -x c 
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/test/Driver/XRay/xray-instrument-os.c
clang -cc1 version 7.0.0 based upon LLVM 7.0.0svn default target 
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.obj/lib/clang/7.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
```

http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/8844/steps/test/logs/stdio

Please revisit and ship a fix.

I've reverted change in this file in HEAD.


Repository:
  rL LLVM

https://reviews.llvm.org/D43378



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

[PATCH] D43614: Define _PTHREADS for -pthread on NetBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski created this revision.
krytarowski added reviewers: joerg, rnk.
krytarowski added a project: clang.
Herald added a subscriber: llvm-commits.

GCC and PCC define _PTHREADS for -pthreads
on NetBSD.

The _PTHREADS preprocessor macro is used in
the NetBSD header in .

NetBSD uses both: _REENTRANT and _PTHREAD
for the -pthreads command line option.

Sponsored by 


Repository:
  rL LLVM

https://reviews.llvm.org/D43614

Files:
  lib/Basic/Targets/OSTargets.h
  test/Driver/netbsd.c


Index: test/Driver/netbsd.c
===
--- test/Driver/netbsd.c
+++ test/Driver/netbsd.c
@@ -431,5 +431,6 @@
 // S-POWERPC64: "{{.*}}/usr/lib{{/|}}crtend.o" 
"{{.*}}/usr/lib{{/|}}crtn.o"
 
 // PTHREAD-NOT: _POSIX_THREADS
+// PTHREAD: _PTHREADS
 // PTHREAD: _REENTRANT
 // PTHREAD-NOT: _POSIX_THREADS
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -362,8 +362,10 @@
 Builder.defineMacro("__NetBSD__");
 Builder.defineMacro("__unix__");
 Builder.defineMacro("__ELF__");
-if (Opts.POSIXThreads)
+if (Opts.POSIXThreads) {
   Builder.defineMacro("_REENTRANT");
+  Builder.defineMacro("_PTHREADS");
+}
   }
 
 public:


Index: test/Driver/netbsd.c
===
--- test/Driver/netbsd.c
+++ test/Driver/netbsd.c
@@ -431,5 +431,6 @@
 // S-POWERPC64: "{{.*}}/usr/lib{{/|}}crtend.o" "{{.*}}/usr/lib{{/|}}crtn.o"
 
 // PTHREAD-NOT: _POSIX_THREADS
+// PTHREAD: _PTHREADS
 // PTHREAD: _REENTRANT
 // PTHREAD-NOT: _POSIX_THREADS
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -362,8 +362,10 @@
 Builder.defineMacro("__NetBSD__");
 Builder.defineMacro("__unix__");
 Builder.defineMacro("__ELF__");
-if (Opts.POSIXThreads)
+if (Opts.POSIXThreads) {
   Builder.defineMacro("_REENTRANT");
+  Builder.defineMacro("_PTHREADS");
+}
   }
 
 public:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43614: Define _PTHREADS for -pthread on NetBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski abandoned this revision.
krytarowski added a comment.

As discussed with Joerg, `_PTHREADS` is considered legacy and we can bear with 
lack of it and inconsistency with GCC.


Repository:
  rL LLVM

https://reviews.llvm.org/D43614



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Looks great! I'm going to test it.


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/ToolChains/NetBSD.cpp:324
 : Generic_ELF(D, Triple, Args) {
   if (getDriver().UseStdLib) {
 // When targeting a 32-bit platform, try the special directory used on

What's the rationale for this condition? Will it work for LLVM `libc++`?


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This works for me!


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Regardless of LLD, `--sysroot` is still needed I think.


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

What software in particular, besides compilers?


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a subscriber: ruiu.
krytarowski added a comment.

@ruiu what's your opinion on this?


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D33726: [driver][netbsd] Build and pass `-L` arguments to the linker

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I concur this, linkers are to used through a compiler frontend and `libtool` 
(which wraps a compiler).


Repository:
  rL LLVM

https://reviews.llvm.org/D33726



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski created this revision.

This adds support for __float128 from GNU libstdc++ with Clang on NetBSD 
x86/x86_64 targets.

This corrects compilation at least of CMake and probably others like Firefox.

In file included from 
/tmp/pkgsrc-tmp/devel/cmake/work/cmake-3.8.2/Source/kwsys/Directory.cxx:4:
In file included from 
/tmp/pkgsrc-tmp/devel/cmake/work/cmake-3.8.2/Source/cmsys/Directory.hxx:8:
In file included from /usr/include/g++/string:40:
In file included from /usr/include/g++/bits/char_traits.h:39:
In file included from /usr/include/g++/bits/stl_algobase.h:64:
In file included from /usr/include/g++/bits/stl_pair.h:59:
In file included from /usr/include/g++/bits/move.h:57:
/usr/include/g++/type_traits:311:39: error: __float128 is not supported on this 
target

  struct __is_floating_point_helper<__float128>
^

Sponsored by 


Repository:
  rL LLVM

https://reviews.llvm.org/D34018

Files:
  lib/Basic/Targets.cpp


Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -514,6 +514,8 @@
 Builder.defineMacro("__ELF__");
 if (Opts.POSIXThreads)
   Builder.defineMacro("_REENTRANT");
+if (this->HasFloat128)
+  Builder.defineMacro("__FLOAT128__");
 
 switch (Triple.getArch()) {
 default:
@@ -530,6 +532,15 @@
   NetBSDTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
 this->MCountName = "_mcount";
+
+switch (Triple.getArch()) {
+default:
+  break;
+case llvm::Triple::x86:
+case llvm::Triple::x86_64:
+  this->HasFloat128 = true;
+  break;
+}
   }
 };
 


Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -514,6 +514,8 @@
 Builder.defineMacro("__ELF__");
 if (Opts.POSIXThreads)
   Builder.defineMacro("_REENTRANT");
+if (this->HasFloat128)
+  Builder.defineMacro("__FLOAT128__");
 
 switch (Triple.getArch()) {
 default:
@@ -530,6 +532,15 @@
   NetBSDTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
 this->MCountName = "_mcount";
+
+switch (Triple.getArch()) {
+default:
+  break;
+case llvm::Triple::x86:
+case llvm::Triple::x86_64:
+  this->HasFloat128 = true;
+  break;
+}
   }
 };
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Softfloat on the NetBSD of Clang/LLVM part?


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Is this sufficient as a test:

  $NetBSD$
  
  --- test/Sema/128bitfloat.cpp.orig2017-05-29 10:06:54.0 +
  +++ test/Sema/128bitfloat.cpp
  @@ -4,6 +4,8 @@
   // RUN: %clang_cc1 -triple i686-windows-gnu -verify -std=c++11 %s
   // RUN: %clang_cc1 -triple x86_64-windows-gnu -verify -std=c++11 %s
   // RUN: %clang_cc1 -triple x86_64-windows-msvc -verify -std=c++11 %s
  +// RUN: %clang_cc1 -triple i386--netbsd -verify -std=c++11 %s
  +// RUN: %clang_cc1 -triple x86_64--netbsd -verify -std=c++11 %s
   
   #if defined(__FLOAT128__) || defined(__SIZEOF_FLOAT128__)
   __float128 f;
  ``


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D34294: Rework libcxx strerror_r handling.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

New one is harder to comprehend and less portable (usage of `__atribute__`).

Can we just replace

  #elif defined(__linux__) && !defined(_LIBCPP_HAS_MUSL_LIBC) &&
 \
  (!defined(__ANDROID__) || __ANDROID_API__ >= 23)

with `#elif __GLIBC__`?


https://reviews.llvm.org/D34294



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

[PATCH] D34294: Rework libcxx strerror_r handling.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Or better:

  #elif __GLIBC__ || (__ANDROID_API__ - 0) >= 23

If I understand correctly, Android adopted GNU version.


https://reviews.llvm.org/D34294



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

[PATCH] D34294: Rework libcxx strerror_r handling.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D34294#782856, @jyknight wrote:

> In https://reviews.llvm.org/D34294#782806, @krytarowski wrote:
>
> > New one is harder to comprehend and less portable (usage of `__atribute__`).
>
>
> I can't disagree more strongly.  This is fundamentally portable C++ code -- 
> __attribute__((unused)) is simply warning suppression.
>  I used it directly, because I saw other .cpp files in libcxx already did so. 
> If it needs to be conditioned, it could be.


OK with me.


https://reviews.llvm.org/D34294



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

ping


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D34018#783218, @joerg wrote:

> As I said, I don't see the point in pretending we support float128 when the 
> runtime doesn't contain the necessary pieces.


On the other hand cmake and other packages break now. What's the alternative?


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

We can patch libstdc++ to conditionally enable float128 on NetBSD, this works 
too. All other systems I'm aware of including cygwin moved to 
`this->HasFloat128 = true;`.


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

We can change NetBSD base libstdc++ in `/usr/include/g++/bits/*/c++config.h` 
from

  /* Define if __float128 is supported on this host. */
  #define _GLIBCXX_USE_FLOAT128 1

to:

  #if !defined(__clang__)
  /* Define if __float128 is supported on this host. */
  #define _GLIBCXX_USE_FLOAT128 1
  #endif


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D41054: Teach clang/NetBSD about additional dependencies for sanitizers

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D41054#955755, @joerg wrote:

> I'm not really a fan of linking libutil into all binaries. Why is this code 
> using forkpty in first place and not posix_openpt/grantpt?




  pid_t
  forkpty(int *amaster, char *name, struct termios *term, struct winsize *winp);

We need to teach sanitizers how to mark as initialized structs passed to this 
function.

Sanitizers are for development only, so it's the trade-off of linking with 
additional libraries.


Repository:
  rL LLVM

https://reviews.llvm.org/D41054



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

[PATCH] D41054: Teach clang/NetBSD about additional dependencies for sanitizers

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

`-lutil` is just the same case as `-lrt` or `-lm` here.

The potential problem with with autoconf and similar is the design problem, not 
NetBSD linking here with -lutil.

Without this -lutil, every sanitizer with interceptors will generate spurious 
dlerror() errors for the lack of `forkpty`.


Repository:
  rL LLVM

https://reviews.llvm.org/D41054



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

[PATCH] D41054: Teach clang/NetBSD about additional dependencies for sanitizers

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In particular, this issue has been detected with dtls_test.c (MSan test), but 
it is valid to every program checking dlerror().

I've pluged more missing symbols through https://reviews.llvm.org/D41053, there 
are still few but I'm now busy with teaching sanitizers about all the NetBSD 
syscalls and all the NetBSD ioctls.

This patch plugs backtrace(3) and forkpty(3) missing symbols.


Repository:
  rL LLVM

https://reviews.llvm.org/D41054



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

[PATCH] D41054: Teach clang/NetBSD about additional dependencies for sanitizers

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Ping?


Repository:
  rL LLVM

https://reviews.llvm.org/D41054



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

[PATCH] D43818: Better OpenBSD frontend support

[Kamil Rytarowski via Phabricator via cfe-commits]

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

OpenBSD ships with an aggressive ASLR (or ASR) implementation with 
fragmentation of user address space. As far as I can tell, it's not possible to 
disable it. This means that you are restricted to UBSan.


Repository:
  rC Clang

https://reviews.llvm.org/D43818



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

[PATCH] D43818: Better OpenBSD frontend support

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

OpenBSD might also have issues with allocating lazily large memory regions for 
metadata, so on amd64 with 40/48-bit address space shadow is extremely large. 
Although it's best to investigate it. Just noting another potential showstopper.


Repository:
  rC Clang

https://reviews.llvm.org/D43818



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

[PATCH] D43818: Better OpenBSD frontend support

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

TSan actually demands a lot of meta-data, similar to MSan.


Repository:
  rC Clang

https://reviews.llvm.org/D43818



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

[PATCH] D43818: Better OpenBSD frontend support

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/ToolChains/CommonArgs.cpp:545
 CmdArgs.push_back("-lpthread");
-CmdArgs.push_back("-lrt");
+if (TC.getTriple().getOS() != llvm::Triple::OpenBSD)
+  CmdArgs.push_back("-lrt");

It's a matter of taste, but I would try to omit nested `if`.


Repository:
  rC Clang

https://reviews.llvm.org/D43818



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

[PATCH] D42644: [asan] Intercept std::rethrow_exception indirectly.

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This looks like broke ASan on NetBSD:

  $ sh 
./projects/compiler-rt/test/sanitizer_common/asan-i386-NetBSD/NetBSD/Output/ttyent.cc.script
  /usr/lib/i386/libgcc.a(unwind-dw2.o): In function `_Unwind_RaiseException':
  unwind-dw2.c:(.text+0x1b41): multiple definition of `_Unwind_RaiseException'
  
/public/llvm-build/lib/clang/7.0.0/lib/netbsd/libclang_rt.asan-i386.a(asan_interceptors.cc.o):/public/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:337:
 first defined here
  clang-7.0: error: linker command failed with exit code 1 (use -v to see 
invocation)

Investigating.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D42644



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

[PATCH] D43961: OpenBSD Driver basic sanitiser support

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

http://llvm.org/viewvc/llvm-project?revision=326652&view=revision

  /export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/bin/clang 
-target x86_64-linux-gnu -fsanitize=hwaddress 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/Driver/fsanitize.c
 -### 2>&1 | 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/bin/FileCheck 
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/Driver/fsanitize.c
 --check-prefix=CHECK-SANHA-X86_64
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  
/export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/Driver/fsanitize.c:18:29:
 error: expected string not found in input
  // CHECK-UNDEFINED-OPENBSD: 
"-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){18}"}}
  ^
  :1:1: note: scanning from here
  clang version 7.0.0 (trunk 326648)
  ^
  
  --
  
  

http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/15071/steps/ninja%20check%201/logs/stdio

Please fix this.


Repository:
  rC Clang

https://reviews.llvm.org/D43961



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

[PATCH] D44069: Test Driver sanitise, unsupported on OpenBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This is not breaking (only?) on OpenBSD, but the triple is breaking all tested 
platforms.
Please support it properly.


Repository:
  rC Clang

https://reviews.llvm.org/D44069



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

[PATCH] D44069: Test Driver sanitise, unsupported on OpenBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Revert: http://llvm.org/viewvc/llvm-project?revision=326652&view=revision

And fix.


Repository:
  rC Clang

https://reviews.llvm.org/D44069



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

[PATCH] D44069: Test Driver sanitise, unsupported on OpenBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Please mark ubsan as supported now.


https://reviews.llvm.org/D44069



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

[PATCH] D44069: Test Driver sanitise, unsupported on OpenBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

While there can we add the remaining sanitizers here, like lsan, msan, tsan, 
esan etc?


https://reviews.llvm.org/D44069



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

[PATCH] D44604: Make stdarg.h compatible with FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

This does not fix the potential problem on NetBSD. We define 
`__VA_LIST_DECLARED` (with extra `_` on the beginning).

The proper solution looks to go for:

  #if __STDC_HOSTED__ && __has_include_next()


Repository:
  rC Clang

https://reviews.llvm.org/D44604



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

[PATCH] D47814: Teach libc++ to use native NetBSD's max_align_t

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski created this revision.
krytarowski added reviewers: chandlerc, dlj, EricWF, joerg.
Herald added a subscriber: llvm-commits.

The NetBSD headers ship with max_align_t, that is not
compatible with the fallback version in libc++.

There is no defined a compiler specific symbol in the headers like:

- __CLANG_MAX_ALIGN_T_DEFINED
- _GCC_MAX_ALIGN_T
- __DEFINED_max_align_t

Sponsored by 


Repository:
  rL LLVM

https://reviews.llvm.org/D47814

Files:
  include/cstddef
  include/stddef.h


Index: include/stddef.h
===
--- include/stddef.h
+++ include/stddef.h
@@ -54,7 +54,7 @@
 
 // Re-use the compiler's  max_align_t where possible.
 #if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T) && \
-!defined(__DEFINED_max_align_t)
+!defined(__DEFINED_max_align_t) && !defined(__NetBSD__)
 typedef long double max_align_t;
 #endif
 
Index: include/cstddef
===
--- include/cstddef
+++ include/cstddef
@@ -50,7 +50,7 @@
 using ::size_t;
 
 #if defined(__CLANG_MAX_ALIGN_T_DEFINED) || defined(_GCC_MAX_ALIGN_T) || \
-defined(__DEFINED_max_align_t)
+defined(__DEFINED_max_align_t) || defined(__NetBSD__)
 // Re-use the compiler's  max_align_t where possible.
 using ::max_align_t;
 #else


Index: include/stddef.h
===
--- include/stddef.h
+++ include/stddef.h
@@ -54,7 +54,7 @@
 
 // Re-use the compiler's  max_align_t where possible.
 #if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T) && \
-!defined(__DEFINED_max_align_t)
+!defined(__DEFINED_max_align_t) && !defined(__NetBSD__)
 typedef long double max_align_t;
 #endif
 
Index: include/cstddef
===
--- include/cstddef
+++ include/cstddef
@@ -50,7 +50,7 @@
 using ::size_t;
 
 #if defined(__CLANG_MAX_ALIGN_T_DEFINED) || defined(_GCC_MAX_ALIGN_T) || \
-defined(__DEFINED_max_align_t)
+defined(__DEFINED_max_align_t) || defined(__NetBSD__)
 // Re-use the compiler's  max_align_t where possible.
 using ::max_align_t;
 #else
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47814: Teach libc++ to use native NetBSD's max_align_t

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

ping


Repository:
  rL LLVM

https://reviews.llvm.org/D47814



___
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 inline comments.



Comment at: lib/CodeGen/BackendUtil.cpp:323
 Opts.ToolType = EfficiencySanitizerOptions::ESAN_CacheFrag;
-  else if (LangOpts.Sanitize.has(SanitizerKind::EfficiencyWorkingSet))
+  else if (T.getOS() == Triple::Linux &&
+LangOpts.Sanitize.has(SanitizerKind::EfficiencyWorkingSet))

Is it possible to port it to FreeBSD and skip some conditions in generic code?


Repository:
  rC Clang

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] D52610: [Esan] Port cache frag to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/CodeGen/BackendUtil.cpp:323
 Opts.ToolType = EfficiencySanitizerOptions::ESAN_CacheFrag;
-  else if (LangOpts.Sanitize.has(SanitizerKind::EfficiencyWorkingSet))
+  else if (T.getOS() == Triple::Linux &&
+LangOpts.Sanitize.has(SanitizerKind::EfficiencyWorkingSet))

devnexen wrote:
> krytarowski wrote:
> > Is it possible to port it to FreeBSD and skip some conditions in generic 
> > code?
> Not for now, working-set hangs at init time on FreeBSD and unit tests had 
> been disabled in the compiler-rt part.
So can the support be extended in compiler-rt? I would find it more useful to 
handle featured sanitizer in the first place.


Repository:
  rC Clang

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] D52610: [Esan] Port cache frag to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D52610#1278743, @devnexen wrote:

> ping working-set on FreeBSD does not seem doable.


Rationale? I don't feel convinced.


Repository:
  rC Clang

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] D52610: [Esan] Port cache frag to FreeBSD

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D52610#1279176, @devnexen wrote:

> - FreeBSD does not have real Linux's clone equivalent.
> - Hangs or crashes during the final report (the shadow mapping is similar as 
> Linux's though).


NetBSD has a clone compatibility syscall... but please try to explain what is 
the algorithm to map to a BSD system.

There must but a way to port it to BSD.


Repository:
  rC Clang

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] D53922: [clangd] fix non linux build

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

For NetBSD:

- `ThreadPriority::Low` select either `SCHED_RR` or `SCHED_FIFO`, call 
sched_get_priority_min() and set pthread_setschedparam().
- `ThreadPriority::Normal` use SCHED_OTHER with `PRI_NONE`.


Repository:
  rL LLVM

https://reviews.llvm.org/D53922



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

[PATCH] D53922: [clangd] fix non linux build

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D53922#1281898, @sammccall wrote:

> In https://reviews.llvm.org/D53922#1281882, @krytarowski wrote:
>
> > For NetBSD:
> >
> > - `ThreadPriority::Low` select either `SCHED_RR` or `SCHED_FIFO`, call 
> > sched_get_priority_min() and set pthread_setschedparam().
>
>
> https://www.netbsd.org/docs/internals/en/chap-processes.htm indicates 
> `SCHED_RR` and `SCHED_FIFO` are real-time priorities on NetBSD, as they are 
> on linux.
>  i.e. higher priority than normal threads, regardless of priority value.


Priority level for SCHED_OTHER cannot be changed (it is dynamic), so the 
applied patch is fine.


Repository:
  rL LLVM

https://reviews.llvm.org/D53922



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

[PATCH] D53922: [clangd] fix non linux build

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In https://reviews.llvm.org/D53922#1281914, @sammccall wrote:

> Thanks. I was replying to your suggestion for NetBSD though - my reading of 
> the docs says your "low" suggestion would end up being a very high priority.
>  Is this not the case? Can you suggest a better reference for how BSD 
> scheduling works?


This reference is fine and the patch restricting it to Linux is fine. I think 
that there is no way to implement it for NetBSD, also it does not seem to be a 
crucial feature.


Repository:
  rL LLVM

https://reviews.llvm.org/D53922



___
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] 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());
+

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] 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 a comment.

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

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

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




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

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

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

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


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

https://reviews.llvm.org/D56215



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

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

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added 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 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.

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

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.

> 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] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski requested review of this revision.
krytarowski added a comment.
Herald added a subscriber: llvm-commits.

This change happened to be required in downstream usage.. knowing its limits 
can we merge it as it is?


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D34018: Support __float128 on NetBSD libstdc++ x86/x86_64

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski planned changes to this revision.
krytarowski added a comment.

OK.


Repository:
  rL LLVM

https://reviews.llvm.org/D34018



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

[PATCH] D54379: Add Hurd support

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added inline comments.



Comment at: lib/Driver/ToolChains/Hurd.cpp:136
+
+  // Add an include of '/include' directly. This isn't provided by default by
+  // system GCCs, but is often used with cross-compiling GCCs, and harmless to

Is this some hurd standard or personal taste?


https://reviews.llvm.org/D54379



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

[PATCH] D54641: [compiler-rt] [cmake] Fix detecting terminfo library

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I have got a local patch in pkgsrc-wip/llvm-netbsd:

  $NetBSD$
  
  --- cmake/config-ix.cmake.orig2017-12-08 18:50:04.615602612 +
  +++ cmake/config-ix.cmake
  @@ -153,7 +153,7 @@ if(NOT LLVM_USE_SANITIZER MATCHES "Memor
   endif()
   if(LLVM_ENABLE_TERMINFO)
 set(HAVE_TERMINFO 0)
  -  foreach(library tinfo terminfo curses ncurses ncursesw)
  +  foreach(library terminfo tinfo curses ncurses ncursesw)
   string(TOUPPER ${library} library_suffix)
   check_library_exists(${library} setupterm "" 
HAVE_TERMINFO_${library_suffix})
   if(HAVE_TERMINFO_${library_suffix})

Shouldn't we apply it here too?


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D54641



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

[PATCH] D54641: [compiler-rt] [cmake] Fix detecting terminfo library

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Context:

> Do not return -ltinfo from llvm-config --system-libs --link-static
> 
> under NetBSD. Bump PKGREVISION
> 
> Rust language 1.20.0 uses these options and Rust build system uses it
>  as '-l tinfo' and our wrapper does not handle this.

https://github.com/NetBSD/pkgsrc/commit/2ca60b7c8cec0e6c0f3100d9439b6d126424ae2d#diff-079668572f99829ef3e9afc048ebc7a0


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D54641



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

[PATCH] D54641: [compiler-rt] [cmake] Fix detecting terminfo library

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

As I understand it -ltinfo vs -lterminfo is mixing native curses(3) and 
external ncurses(3) from pkgsrc, while we prefer to use entirely our native 
version for all LLVM projects.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D54641



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

[PATCH] D54641: [compiler-rt] [cmake] Fix detecting terminfo library

[Kamil Rytarowski via Phabricator via cfe-commits]

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

In https://reviews.llvm.org/D54641#1301620, @mgorny wrote:

> Well, sure but I think changing the order should be done separately from 
> this. I'm fixing a bug resulting from people deciding to customize code 
> instead of keeping it in sync; so I'd rather not combine it with 
> intentionally mis-syncing the code.


It will be good to evaluate the changed order (in particular whether it still 
works fine on Linux).


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D54641



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

[PATCH] D55441: [lld] [test] Fix reproduce-blackslash.s test with NetBSD tar

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In my opinion it's better to set UNSUPPORTED and align the NetBSD tar to GNU 
tar and libarchive.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D55441



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

[PATCH] D55441: [lld] [test] Fix reproduce-blackslash.s test with NetBSD tar

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

bsdtar is libarchive (by BSD people too)

We can align our native tar later and land this as is.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D55441



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

[PATCH] D55443: [test] Capture stderr from 'tar --version' call as well

[Kamil Rytarowski via Phabricator via cfe-commits]

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

I don't feel enough comfortable with this Python code.


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

https://reviews.llvm.org/D55443



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://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] 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] 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] 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] 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