This check should contain additional check for uid==root. If we are root we can read and write to DB registers.

I would leave the NetBSD version as it is in this patch and let us to fix/test it later.

This change makes NetBSD buildbot flaky.

In general this code should be close to functional on NetBSD (if not already compatible).

In D59744#1529218, @mgorny wrote:

In D59744#1529182, @krytarowski wrote:

In D59744#1527412, @wxiao3 wrote:

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

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

Probably yes. FWICS, gcc uses %mm0 and %mm1 on NetBSD while clang doesn't.

In D59744#1527412, @wxiao3 wrote:

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

This commit breaks the NetBSD buildbot node.

If we want to reject opening directories we shall do it during open(2)/fopen(3).

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

whereas others emit "is a directory

In D62499#1520654, @labath wrote:

In D62499#1520610, @krytarowski wrote:

One time just before it's loaded (so lldb can check which modules are loaded) and another right after it's loaded (so lldb can check again which ones are loaded and calculate the difference).

There is on NetBSD and on a selection of other OSs: _rtld_debug_state integrated as a part of ELF dynamic loader.

Is there something like that on Android that could be reused?

Yes, there is, and it's being used now. The question here is what do we do *after* we hit the dynamic loader breakpoint...

One time just before it's loaded (so lldb can check which modules are loaded) and another right after it's loaded (so lldb can check again which ones are loaded and calculate the difference).

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

I think there is a bug thought in the code.

In D60728#1469794, @hans wrote:

In D60728#1468713, @krytarowski wrote:

In D60728#1468486, @hans wrote:

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

Raise awareness about the problem.

I don't think that works. No one is reading through the test files of the repository.

In D60728#1468486, @hans wrote:

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

Adding @void, regression introduced with D55616.

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

I think depending on CMAKE_THREAD_LIBS_INIT is the way to go. If it is broken for some platform internally, such OS has more issues than building OpenMP.

We have observed regressions in UI responsiveness on Linux and Windows when clangd is doing background indexing at normal priority.

In D59451#1432542, @dim wrote:

In D59451#1432417, @krytarowski wrote:

it's not with libc++ and newer libstdc++.

Some OSs merged libpthread into libc and/or implemented it almost fully in the kernel. It's not the case on NetBSD and apparently FreeBSD.

In libc there are just stubs for libpthread to allow linking but without defined interfaces, unless someone will link with the POSIX threading library.

Indeed, at least on FreeBSD there is a desire to fold the full pthread interface into libc, but it's apparently not very easy to do. So for now we need -pthread or -lpthread during linking.

One other thing that could be done is to link libc++.so.1 with -lpthread, but that would make every consumer of libc++ depend on the threading libraries, even if they never use any of the std::thread functionality. At least in our system version of libc++, we've never linked it with the threading libraries, but maybe it's something we should consider. @emaste any thoughts?

it's not with libc++ and newer libstdc++.

Hmm, looks like this used to be true (for example with libstdc++ from GCC 4.8 found in CentOS 7), but it's not with libc++ and newer libstdc++.

In D59451#1432390, @Hahnfeld wrote:

So if a developer uses a feature from stdlib, they need to manually link libpthread?

I'm not sure about OMP specifics, but in C++ threads we are allowed to use threading routines but in order to make them functional we must link final executable with libpthread.

In D59451#1431917, @dim wrote:

In D59451#1431899, @krytarowski wrote:

If we want to depend on pthread, please go for canonical -pthread.

Hm, I copied this from several other tests, which use the same construct, so I don't see why this one should be different. (In fact pthread detection is a can of worms, many configure scripts go through extreme lengths to determine the exact magical incantation needed... but most of the time -lpthread works everywhere, except on Windows of course. :) )

If we want to depend on pthread, please go for canonical -pthread.

It looks good to me, but maybe @JDevlieghere has a better idea how to optimize it.

Looks good, but I would hold on a little bit until the situation will stabilize. We might want to add additional scenario of jemalloc.h and MALLCTL interfaces in -ljemalloc. But either way this patch is an improvement.

I would port it to NetBSD... but I don't see use-case for it. I think kernel should be allowed to schedule priorities on its own without manual help.

In D59133#1422960, @eugenis wrote:

LGTM, good job!

Regarding dfsan, I think it has users @pcc

In D59133#1422906, @thakis wrote:

In D59133#1422851, @krytarowski wrote:

How about DFSan and shadowcallstack?

I don't understand how that question is related to this change. What do you mean?

How about DFSan and shadowcallstack?

Looks good to me.

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.

@ruiu ping?

Feel free to commit this and next without review.

The NetBSD buildbot is broken after this change.

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

We need to use our current approach with factory... we are actively working on LLDB test targets and we will be attaching compiler-rt next.

In D58505#1405760, @mgorny wrote:

In D58505#1405719, @Hahnfeld wrote:

Would it make sense to rename the builder? lldb-amd64-ninja-netbsd8 is just not true based on that list. IIRC there are other unified bots, that test a variety of projects?

Apparently Fuchsia has one, and puts it in 'toolchain' category. Maybe we should just name it 'amd64-ninja-netbsd8' or 'netbsd8-amd64-ninja'. Are you maybe aware if rename is something that can be done lightly in zorg, or does it require some extra work?

In D58505#1405719, @Hahnfeld wrote:

Would it make sense to rename the builder? lldb-amd64-ninja-netbsd8 is just not true based on that list. IIRC there are other unified bots, that test a variety of projects?

I would include compiler-rt in one go as we will enable its builds sooner than later.

This broke the NetBSD buildbot: http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8/builds/19082

<strings.h> should be included unconditionally.

Please enable the tests for NetBSD as well.

bcmp is BSD and it first appeard in 4.2BSD... it's not specific to GNU source but compat layer for BSD software.

@mgorny let's go through tech-kern@ and later checking FreeBSD/Darwin/OpenBSD. I think it's worth to clarify this in the documentation.

In D58230#1398529, @mgorny wrote:

In D58230#1398020, @krytarowski wrote:

For EINTR we shall use llvm::sys::RetryAfterSignal

kevent() man page indicates:

All changes contained in the changelist are applied before any pending events are read from the queue.

Also:

[EINTR] A signal was delivered before the timeout expired and before any events were placed on the kqueue for return.

So while it's not stated explicitly, I think in_events is always consumed, even if EINTR is returned. In which case, llvm::sys::RetryAfterSignal would be wrong whenever in_events is not empty.

It looks good to me.

'attaching a debugger produces an observable side-effect (EINTR) in the debugged process is considered a bug by the linux kernel folks'

For EINTR we shall use llvm::sys::RetryAfterSignal

Short term this looks fine.

In D57959#1390992, @mgorny wrote:

But to what purpose? I think it's better to use consistent macros to refer to the same scenario.

In D57959#1390929, @mgorny wrote:

Ok, I see that _WIN32 actually redefines sigset_t, so I've added a separate branch for it.

@labath our short-term goal is to enable execution of LLDB tests on the NetBSD buildbot. We are stuck temporarily with an older release of NetBSD on the machine for some time (1-2 months) so we need to live with it for now. No need to make it better than sufficient as of now.

I think that sigemptyset(2) is unsupported on Windows.