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.

The NetBSD buildbot breaks in these tests now:

The NetBSD buildbot is affected and red for some time now.

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.

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 pass flags from clang, we sacrifice:

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

In D57412#1376056, @cryptoad wrote:

In D57412#1376046, @krytarowski wrote:

I have got a scudo support patch for NetBSD locally.. but the original tests are havily prepared against GNU malloc. This makes me uncertain whether scudo really works. Are there plans to make the tests more generic?

That should be the case for the unit-tests. The new way things are done will clearly separate the C/C++ wrappers.
I can add you on the standalone check-ins for you to chime in on the direction we are headed to.
All the development efforts so far has targeted Linux/Android/Fuchsia, and I unfortunately have no BSD knowledge, but we are definitely open to contributions.
Initial check-ins will be Linux specific though since it's my workstation and that's what I am testing things against.

I wouldn't pursue work on your side on the current non-standalone Scudo, as the standalone version will be better (more performant, smaller memory footprint, etc) on all fronts.

I have got a scudo support patch for NetBSD locally.. but the original tests are havily prepared against GNU malloc. This makes me uncertain whether scudo really works. Are there plans to make the tests more generic?

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.

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.

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

NetBSD is affected in the same way.

In D56975#1364959, @joerg wrote:

I'd really prefer to keep the argv[0] code as is. I'm not sure what that test case is supposed to do, but it seems quite questionable as "check" is not a valid language frontend nor a version suffix. It should not work.