(!defined(__MUSL__) || !__MUSL__) is pretty ugly. There is obviously a need for SANITIZER_MUSL, but then it's up to Linux maintainers whether to accept it.

LLVM Release Schedule: 10.0.0: Jan 15, 2020: branch, then rc1

Ping?

• rebase to HEAD

@MaskRay I will mail you off-list with one question.

Ping?

If possible, it would be nice to follow up with heapsort(3) and mergesort(3).

We would like to get this PT_LOAD split as a tunable, ignoring whether tests are passed or not when it is disabled.

Stating it from a different side. If you do not care about GNU ld drop-in replacement property for Linux it's not our business, but we do care about this in NetBSD and we restrict this to our project only (from ELF targets). If you do not care about NetBSD, you shall not care how and whether we use LLD. We try hard to not interfere with Linux looking for a consensus.

@joerg works on the ELF loader and we just need to wait for him. We wrote our temporary patch, but it was not ideal as the long term solution.

We attempted to patch internally LLD rebasing our code for the buildbot purposes but LLD without being used rots quickly, see: https://reviews.llvm.org/D58892

In D70958#1767912, @eugenis wrote:

Could this go into the common lit config in compiler-rt/test?

Ping?

In D70025#1758800, @labath wrote:

LGTM, since this seems to be the best we can do given the current netbsd behavior.

However, I'd like to repeat what I said on the IRC, that I consider this behavior of netbsd to be unreasonable.

We are in the process of switching our buildbot to newer NetBSD snapshot (-8 to -9) and we keep waiting for this patch to land.

ping?

Short summary:

-o is an unportable extension.

Better patch in https://reviews.llvm.org/D70048

• fix a typo in a comment.

Another approach to achieve the same goal as previous attempts. It is already better as it avoids two forks.

How does it deal with security.models.extensions.user_set_dbregs? If there is a handled error than it's fine.

burden with the upstream

I don't want to diverge this patch on offtopic or general discussion.

In D69755#1731394, @MaskRay wrote:

I still have the feeling that such configurations should be added to clangDriver/gcc specs or a shell script wrapper of lld.

• upload diff with wider context

Same here, I cannot commit.

In D68856#1718096, @lawrence_danna wrote:

now I'm stuck on this trying to install cmake.

pkg_add: no pkg found for 'libunistring>=0.9.4', sorry.
pkg_add: Can't install dependency libunistring>=0.9.4
pkg_add: 1 package addition failed
*** Error code 1

For the git part you will need to install mozilla-rootcerts and follow post-install instructions, as otherwise https:// won't work nicely.

In D68856#1717683, @lawrence_danna wrote:

@mgorny

I can't get anything to work. I've tried running a local VM with virtualbox but it's networking driver crashes my kernel. I've tried a local VM with VMware but it won't boot netbsd. I've tried AWS but they only have netbsd 7, which is too old. I've tried google cloud, but their image creator script only works for netbsd 9, and python won't build because x11 isn't installed. I've tried installing the pkgsrc binaries from netbsd 8 onto netbsd 9, but that doesn't work either. I'm completely at a loss. I can't figure out how to make a netbsd VM that can actually build LLDB.

Do you have a machine image on AWS or google cloud or even a VMDK or something that I could use?

This looks good as an intermediate step to make lld saner.

In D67908#1678816, @fjricci wrote:

Interesting - I had tried to add has_feature for lsan to clang in the past and couldn’t get the change accepted. Nice to see it works now :)

Once GCC will grow support for __SANITIZER_LEAK__ (already pending in review) there will be include as a separate patch support for LSan/GCC.

This is needed in the NetBSD kernel, more fine-grained checks would be acceptable too, but one global feature detection is what I need.

With these patches included there are still ~3 failing tests and I will mark them as XFAIL for now.

In D67331#1677564, @vitalybuka wrote:

Tests?

Looks good to me but I will leave the final decision to someone else.

• apply changes from review

• apply changes from review

• restrict __lsan::ScopedInterceptorDisabler to ASan and LSan