I'm trying to find which macOS version added _platform_memchr$VARIANT$Base (see https://bugs.kde.org/show_bug.cgi?id=43779 for details, a request to get this handled properly by Valgrind).

I'm looking at getting Valgrind to run on macOS 10.15 Catalina.So far I have the build working OK (based on a fork for 10.14 plus a few tweaks specific to 10.15).However when I run Valgrind [and I'm running the minimal --tool=none with an app that is just "int main(void) {}"] then I'm getting an error related to pthread_init. From what I see from the executed machine code, there is a test for _os_xbs_chrooted (a global variable in the kernel by the looks of it) which then leads to a call to __pthread_init.cold.2. This function contains a ud2 opcode which triggers a SIGILL in the Valgrind VM.Dearching google for _os_xbs_chrooted doesn't come up with anything much. There's this https://github.com/apple/darwin-libpthread/blob/master/src/pthread.c for the pthread check, and one other reference for the initialization.I realize this looks like it could be security related and information is not made public.Any suggestions as to how I can proceed? I have little experience in kernel programming.

[I've already asked this on llvm discourse, no answer yet] Can someone give me a brief intro or point me to documentation that describes how lldb handles the dyld shared cache on macOS? I’m trying to evaluate how to implement the same functionality in Valgrind. Prior to macOS 11 Big Sur Valgrind used DYLD_SHARED_REGION=avoid to force loading the libraries and then to bypass the cache and so to trigger reading the mach-o info to be able to redirect malloc/pthread functions. Without these redirs not much is working correctly.

Does macOS have anything like the FreeBSD macro _FreeBSD_version? That's a macro that gets bumped whenever kernel interfaces change, see https://docs.freebsd.org/en/books/porters-handbook/versions/

I posted about this about 5 years ago, and now at last it's close to being finished. The main problem that I now have is related to matching up DWARF debuginfo and global variables. This works fairly well on macOS 10.14. On 10.15 much less so, and I think that the reason is how the macho data is mmap'd. When Valgrind runs it does the job of the OS and loads the guest exe into memory. It'll then load and run dyld in Valgrind. I can get memory map debug traces. In one test with a problem I see 4 load segments. __DATA_CONST and __DATA both have prot 3 (RW) so we load them RW and not R then RW. Then I think that dyld munmaps and re mmaps the _DATA_CONST segment as RO. Valgrind works based on mmaps triggering reading debuginfo. I don't think that it handles munmap correctly. I need to debug that a lot more - I can see the changed mappings in the debug output but I don't see exactly what is happening with munmap and mmap (unless dyld is doing that on a section by basis). Does what I'm saying about the mappings make any sense?