In general -fPIC is probably the way to go.. but I don't know about this particular case. I defer decision to FreeBSD maintainers.

What's the error message?

In D51419#1224011, @vitalybuka wrote:

Now SANITIZER_NETBSD shares almost nothing with the rest
May I ask you to create sanitizer_netbsd.cc and move code there?

ping?

https://llvm.org/docs/HowToAddABuilder.html

Adding some more context, there are a few remixes of FreeBSD such as TruOS, GhostBSD, DesktopBSD etc... and all of them are custom reconfiguration of defaults and they keep self recognition to __FreeBSD__. MidnightBSD is similar, it's a remix of FreeBSD with GNUSTEP. For some reason the project decided to fork the FreeBSD distribution entirely, however over the years there were no[t so many] distinct features to recognize this OS as a distinct version of BSD ( https://github.com/freebsd/freebsd/blob/master/share/misc/bsd-family-tree ).

In D51577#1221922, @arsenm wrote:

Are there any actual codegen changes vs. FreeBSD, since you seem to have just added handling to everywhere FreeBSD is? if not, can you just make this an alias of freebsd in the triple parsing?

Why to patch mips-specific code for MidnightBSD? Why to patch code for sanitizers and instrumentation in general?

When possible, switch indirect calls to direct calls of internal libc symbols.

What's the internal variant for e.g. dup2(2) or getpid(2)?

OK, it looks like these ones are cancel points. I will switch them to _sys_.

Personally, I prefer to go for public symbols as with next major libc bump, they might stay around. So not depend too much on the internals that shall be rather not used by 3rd party software.

_sys_ seems to be available only for a small set of of system calls and is not universal.

In D51419#1217377, @devnexen wrote:

Just curious, any impact in term of performance ?

I will prepare a test and submit as a new revision to review.

Do you mean a test for strtoumax(3)?

ping?

NetBSD is fixed, as I was observing previously:

I'm going to test NetBSD soon.

From NetBSD point of view, this looks fine, 1.4.1 contains upstreamed support.

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

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

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.

In D50413#1192475, @cdavis5x wrote:

In D50413#1191726, @krytarowski wrote:

NetBSD uses typedef void *_Unwind_Ptr; unconditionally in its <unwind.h>... if that has to be matched.

Done.

Additionally: typedef long _Unwind_Word;.

Done.

NetBSD uses typedef void *_Unwind_Ptr; unconditionally in its <unwind.h>... if that has to be matched.

Through pkgsrc a user can install LLDB with either style of distribution, including GCC with libstdc++ one (I'm using this myself also for the development of LLVM related code).

Probably the former with ship GDB at least for long time, the latter will switch to LLDB.

NetBSD ships with GCC style and Clang style userland. The former one ships with GNU libstdc++, the latter with libc++.

A problem is that NetBSD is probably the only mainstream OS left using gnu ld (at least for linking Clang/LLVM) and we catch issues of ld vs gold/lld on NetBSD.

In D48806#1150208, @devnexen wrote:

Maybe we need to move from pthread_get/set_specific ? https://reviews.llvm.org/D47448

ping^3

ping^4

In D47448#1149018, @MaskRay wrote:

In D47448#1149017, @krytarowski wrote:

Fixed for FreeBSD? There is still a problem for NetBSD, but I'm still swamped with other things.

Fixed for FreeBSD 12.0-CURRENT (which lives in my qemu :( ). Other have told me OpenBSD is good. What's the issue for NetBSD?

Fixed for FreeBSD? There is still a problem for NetBSD, but I'm still swamped with other things.

Please add comments why tests are failed/unsupported.

It's similar to MUSL, __DEFINED_max_align_t is musl specific and they don't care about libc++ or not on top of it.

I saw this and I think that it shall be handled in libc++. NetBSD doesn't care if c++ runtime library is libstdc++, libc++, none or a different one.

ping^3

ping^2

ping

ping2

In D47977#1127236, @devnexen wrote:

I understand your points, but usually see the jobs are often bound to cpu0 while this cpu can be potentially pretty busy.
But I put it as an option it s something not to be forced.

What's the gain? Performance improvement? What are the numbers for benchmarking?

It causes breakage because there is called an interceptor inside libc that is reported as false positive.

In D46545#1126617, @Lekensteyn wrote:

In D46545#1126599, @krytarowski wrote:

We are now requiring this on NetBSD for MSanitized userland. Some programs break without puts(3) / fputs(3) interceptors there.

Is there a link/discussion to this issue? (f)puts just read from a buffer, how would lack of interceptors cause MSan to break?
I found https://github.com/google/sanitizers/issues/955, but it does not directly mention such an issue.

(This change is still on my TODO list.)

We are now requiring this on NetBSD for MSanitized userland. Some programs break without puts(3) / fputs(3) interceptors there.

I've got a local patch that detect building .a file for each arch separately:

@phosek ^

I think that this is broken for multilib (-m32 + -m64 builds, the default one for NetBSD, Linux, FreeBSD and maybe others):

ping?

ping?

I'm not sure whether this is equivalent.

They claim to sync with FreeBSD daily.. so perhaps they should first try to upstream ASLR to FreeBSD.

I don't know about other BSDs, I've never installed them.

+ chandlerc (CMake maintainer)
+ ruiu (lld maintainer for insight)

The original reason to switch NetBSD to wide characters was to unbreak the input parser. It used to mix wide and short characters.

In the PaX ASLR NetBSD implementation we add a random offset to all allocations including text (for PIE programs), heap and stack.

NetBSD is also affected. We shall go for a shared solution at least between BSDs and Linux.

This design is most likely the same on all current BSDs. OpenBSD borrowed UVM from NetBSD. FreeBSD has its distinct memory subsystem.

On NetBSD NORESERVE is enforced by default, so this flag is dummy.

I defer it to maintainers!

The code looks fine.. but I don't like the description.

Addressed by @vitalybuka.

I need to align both in order to make it to work.

This is an intermediate commit. I'm unloading local patches.