NetBSD and FreeBSD do not support non-stop in the kernel.

Looks still fine.

There is an unhandled comment.

Looks good

Looks correct.

Looks good

Looks good

Let's see.

Looks reasonable

Looks correct.

Looks good.

Sanitizers run on NetBSD/sparc64.

Looks ok for NetBSD.

NetBSD OK!

MAP_NORESERVE is dead on NetBSD as this is the default mode always.

Would it be possible for NetBSD to also use this approach for the libc_pthread_ functions? Or is only a subset exported as libc_pthread_?

Can you follow the NetBSD approach and go for something like TSAN_MAYBE_INTERCEPT_NETBSD_ALIAS instead of patching shared code between all platforms?

Merging is a good idea as NetBSD might duplicate these code chunks too.

In D95696#2532032, @strejda wrote:

Oki, I see, thanks for response. Please give me a few days to analyze (and eventually to implement).

@clayborg please have a look!

These symbols are usually macros + libc calls.

NetBSD uses macros too, but undefines them inside the header for __cplusplus. The proposed patch looks fine. This is a common source of portability issues, the stdio macros.

In D93848#2472902, @MaskRay wrote:

In D93848#2472833, @krytarowski wrote:

Well... technically speaking GLIBC is at least: GNU/Linux, GNU/FreeBSD and HURD.

Hurd and GNU/kFreeBSD are not supported. Even if they do, many defined(__GLIBC__) is inside a #if SANITIZER_LINUX, so they will work automatically.

Well... technically speaking GLIBC is at least: GNU/Linux, GNU/FreeBSD and HURD.

Please include stdlib.h for alloca, unless you target SunOS. alloca.h is unavailable on NetBSD.

In D92667#2434223, @emaste wrote:

No objection here. I'm curious why the two modified tests work on Linux or NetBSD today though?

Ideally we should iterate over the startup process and investigate the state of the r_debug structure. Once it gets initialized, set the software brakpoint to r_brk and keep track of the dynamic loading and unloading of libraries. The tricky part is to detect the right moment to plug into r_brk, early enough in the startup process before calling constructors, loading the libraries etc and late enough to become initialized.

In D92187#2424109, @emaste wrote:

One thing that FreeBSD should do, is to upgrade to the protocol version 1 (stored in r_version), like Linux, NetBSD and OpenBSD.

It looks like Linux has always used r_version=1 (since 1995).

AFAICT we can just add r_ldbase and set version to 1.
See https://reviews.freebsd.org/D27429

In D92187#2423018, @emaste wrote:

I'm curious how gdb handles this, and asked @bsdjhb if he knows off hand.

Is there a brief description of how this works on Linux and/or NetBSD?

I would mark stmmX as an alias to stX and keep stX as the default for all platforms. stmmX could be an alias for everybody for legacy reasons.

I propose to filter all user induced signals at once and check & 0x10000 and SI_USER.

I wonder why NetBSD fails having the same event handling.

In D90757#2378404, @theraven wrote:

Does the new plugin work with processes that are created with pdfork? The last time I tried this, it caused the old plugin to lock up the debugger entirely. Please can you ensure that there are tests that cover pdfork and cap_enter in the child? These are currently quite badly broken.

It's relevant but I encountered issues to pass the review..

Looks OK from the NetBSD point of view.

Host a LLVM buildbot for DragonFly first, otherwise it will be even not ever build-tested.

Please leave builtins intact. ubsan might work, but removing it too is fine.

Please, First remove unused + unusable code for already introduced OS. At most cutting it to ubsan.

This contains unrelated code to ubsan/dragonflybsd. While there can you remove unsupported code for other OSs you introduced? That was never operational?

In D89182#2324267, @labath wrote:

FWIW, PTHREAD_KILL is strongly discouraged on linux. But if the situation is different on freebsd, then fine.

+ @bsdjhb John, could you have a look?

Can we rename the register names in the darwin plugin?