Is this Linux-only?

Committed non-controversial chunks of this. The rest is rescheduled for future in separate review.

In D54641#1301620, @mgorny wrote:

Well, sure but I think changing the order should be done separately from this. I'm fixing a bug resulting from people deciding to customize code instead of keeping it in sync; so I'd rather not combine it with intentionally mis-syncing the code.

As I understand it -ltinfo vs -lterminfo is mixing native curses(3) and external ncurses(3) from pkgsrc, while we prefer to use entirely our native version for all LLVM projects.

Do not return -ltinfo from llvm-config --system-libs --link-static

under NetBSD. Bump PKGREVISION

Rust language 1.20.0 uses these options and Rust build system uses it
as '-l tinfo' and our wrapper does not handle this.

I have got a local patch in pkgsrc-wip/llvm-netbsd:

• add more tests
• add missing rename

@hfinkel any comments on this? If not I recommend to land this patch as it is.

In D54099#1296841, @ro wrote:

In D54099#1293960, @krytarowski wrote:

There is also sparc and sparc64 support in sanitizers on NetBSD... but I cannot say for now how well it works. For sure we run UBSan and ASan for both of them.

I still wonder how this works, though: I've just refreshed my patch for SPARC support in compiler-rt (https://reviews.llvm.org/D40900) and tried
again with patches on top to enable asan on 32-bit sparc in clang and the 32-bit asan tests in compiler-rt (trivial, but not submitted as pointless).

I immediately ran again into build failures of the compiler-rt asan tests:

fatal error: error in backend: Function "main": over-aligned dynamic alloca not supported.
clang-8: error: clang frontend command failed with exit code 70 (use -v to see invocation)

just the same as when I initially had submitted D40900. If you have a way around this, I'm all ears ;-)

I cannot reasonably try sparcv9 on Solaris, though, due to the particular address space layout used there.

However, as I mentioned since about a week an implementation of the TARGET_ASAN_SHADOW_OFFSET hook for sparc has landed in
gcc mainline, where asan works reasonably well.

ubsan should be no problem, admittedly.

There is also start_deactivated in ASan.

It's not complete, there is remaining L24.

Please replace defined(BSD).

In D54338#1294141, @sthibaul wrote:

So that'd be it? I don't know if libcxx supports more than free/net/open bsd and apple ?

Thanks @mgorny for debugging on Linux.

• fix Linux

There is also sparc and sparc64 support in sanitizers on NetBSD... but I cannot say for now how well it works. For sure we run UBSan and ASan for both of them.

Yes, please iterate over explicit BSDs. We don't support BSD4.4 or BSD/OS or such.

In D53975#1289005, @kubamracek wrote:

They're not open source. The interface to them is at https://opensource.apple.com/source/Libc/Libc-498/include/malloc/malloc.h.

• add more checks

• apply fixes from review

On NetBSD one has to check PaX MPROTECT property of a traced process.

ping

ping

ping

Ping?

In this test parent_tid = 1, child_tid = 1 always and distinguishing this way child and parent is broken. Switching syscall_gettid() to behave like getpid() is not sufficient as the test has assumptions that thread is like pid.

Why? We already put a lot of effort into reusing code from LLVM.

Interesting, are these tools open-source? I would be interested to port them to NetBSD.

Is this out of process only to enumarate? Is there an option to support this through debugging interfaces and analysis of a program?

This test seems to have a Linux assumption and I have concerns how to port it to NetBSD.

The proper way to handle is to go for wrapping it with strtod(3), however it requires refactoring of existing sanitizers (msan, dfsan...).

OK.

This change happened to be required in downstream usage.. knowing its limits can we merge it as it is?

I will abandon it for now, if it will make problems again I will show up with a new patch.

@hfinkel I would still like to drop W|X support from MemoryBlock for everybody, restricting this class to swapping between RW and RX in JIT code. For those who need RWX allocations it's more convenient to add a dedicated allocator (and NetBSD can support it). It's just a matter of time when new features on security hardened OSes will break and lose feature parity.

+ hfinkel for JIT API reference.

This looks fine to me.

Ping?

Remove unwanted SI_MAC.

Adding @ro for check whether it's fine for Solaris and SPARC.

In D53863#1280795, @vitalybuka wrote:

is this covered with existing test?

The NetBSD part looks fine. I will be out of the office soon as I will visit California for GSoC Mentor Summit and MeetBSDCa (until October 23rd).

In D52532#1250404, @labath wrote:

In D52532#1246173, @krytarowski wrote:

I was wondering whether we want to normalize this inside the kernel and always advance the Program Counter.. but it's easier to manage it in userland.

I am generally in favour of keeping the kernel simple, particularly when ptrace is concerned. However, there is one difference in behaviour that annoys me. Right now, if an application itself inserts a trap into it's source code, on intel it will be easy to resume it from debugger simply by continuing. OTOH, on arm, the user will have to manually update the PC first. So I am not sure which is better here...

• reduce code duplication with addition of helper macros

• add CHECK()
• add forgotten TgKill()