- User Since
- Aug 30 2015, 11:51 AM (189 w, 5 d)
Wed, Apr 17
Tue, Apr 16
@void hi, this broke assembly code on NetBSD for various archs and blocks upgrade of the toolchain.
Fri, Apr 5
Tue, Apr 2
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.
Sun, Mar 31
Mar 19 2019
We have observed regressions in UI responsiveness on Linux and Windows when clangd is doing background indexing at normal priority.
Mar 17 2019
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++.
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.
Mar 16 2019
If we want to depend on pthread, please go for canonical -pthread.
Mar 15 2019
It looks good to me, but maybe @JDevlieghere has a better idea how to optimize it.
Mar 12 2019
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.
Mar 10 2019
Mar 9 2019
Mar 8 2019
How about DFSan and shadowcallstack?
Mar 7 2019
Looks good to me.
Mar 4 2019
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.
Mar 3 2019
Feel free to commit this and next without review.
Mar 1 2019
The NetBSD buildbot is broken after this change.
Feb 24 2019
This will make life much more easier now with this change.
Feb 22 2019
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.
Feb 21 2019
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
Feb 19 2019
<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.
Feb 18 2019
Feb 15 2019
@mgorny let's go through tech-kern@ and later checking FreeBSD/Darwin/OpenBSD. I think it's worth to clarify this in the documentation.
Feb 14 2019
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
Feb 12 2019
Short term this looks fine.
Feb 9 2019
Feb 8 2019
@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.
Feb 7 2019
Feb 5 2019
Feb 3 2019
The NetBSD buildbot breaks in these tests now:
Feb 2 2019
Feb 1 2019
The NetBSD buildbot is affected and red for some time now.
Jan 30 2019
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.
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.
Jan 29 2019
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?
Jan 27 2019
Can we fix it for everybody? It's certainly not restricted to NetBSD.
Jan 24 2019
NetBSD is affected in the same way.