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

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

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

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 mat

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

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 __

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

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/mailma

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

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

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

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/mailm

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

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:/

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

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:

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

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

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

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-

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

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

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

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

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-commit

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

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 __

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

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

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

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

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

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

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 ___

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

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 wi

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

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` her

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

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/list

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

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()); Mi

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

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()); de

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

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)

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

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 ```

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

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: _REE

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

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-c

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

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

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 con

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

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

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-co

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

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

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/mailma

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

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:

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

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/Director

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

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

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

[PATCH] D34294: Rework libcxx strerror_r handling.

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__`? http

[PATCH] D34294: Rework libcxx strerror_r handling.

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

[PATCH] D34294: Rework libcxx strerror_r handling.

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

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

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

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

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

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 __

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

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. */ #defi

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

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, s

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

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 f

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

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 abo

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

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

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 Cl

[PATCH] D43818: Better OpenBSD frontend support

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 htt

[PATCH] D43818: Better OpenBSD frontend support

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/cf

[PATCH] D43818: Better OpenBSD frontend support

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

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

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

[PATCH] D43961: OpenBSD Driver basic sanitiser support

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/Drive

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

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@list

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

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/cg

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

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

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/listin

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

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 _

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

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 heade

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

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

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

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

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

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

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-commi

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

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 p

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

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 __

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

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 pthre

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

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 bette

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

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

[PATCH] D56607: [clang] [NetBSD] Enable additional sanitizer types

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 ___

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

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 unp

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

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.

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

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

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

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 wheth

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

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 wi

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

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

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

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 iss

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

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 s

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

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

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

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

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

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

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

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 Cher

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

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

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

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 desi

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

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

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

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 _

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

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

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 st

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

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_ENABL

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

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/NetB

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

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 __

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

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 d

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

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

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

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 _

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

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 __

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

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-comm

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

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 wil

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

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

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

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/ h

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

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

  1   2   3   >