[Cross-post from github because I posted there before realizing it wasn't phabricator; apologies for the spam]

In D156821#4600086, @MaskRay wrote:

Failed Tests (4):
  LLVM :: CodeGen/RISCV/rvv/fixed-vectors-int.ll
  LLVM :: CodeGen/SystemZ/ctpop-01.ll
  LLVM :: MC/ARM/basic-thumb2-instructions.s
  LLVM :: tools/llvm-readobj/ELF/relocations.test

AFAICT these failures have been fixed and the change can reland after the clang/ test is fixed.

This patch might have broke the buildbots, starting with when it was first built in https://lab.llvm.org/buildbot/#/builders/85/builds/18390

/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/libcxx_build_ubsan/include/c++/v1/stdlib.h:114:25: runtime error: negation of -9223372036854775808 cannot be represented in type 'long'; cast to an unsigned type to negate this value to itself
    #0 0x5586b6dfb9aa in abs /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/libcxx_build_ubsan/include/c++/v1/stdlib.h:114:10
    #1 0x5586b6dfb9aa in (anonymous namespace)::GNUELFDumper<llvm::object::ELFType<(llvm::support::endianness)1, true>>::printRelRelaReloc((anonymous namespace)::Relocation<llvm::object::ELFType<(llvm::support::endianness)1, true>> const&, (anonymous namespace)::RelSymbol<llvm::object::ELFType<(llvm::support::endianness)1, true>> const&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/tools/llvm-readobj/ELFDumper.cpp:3778:21

(which is good insofar as it finds a real bug, but nonetheless is turning the buildbots red)

@probinson Ah, I overlooked that! Thanks for the quick update.

The re-applied commit (https://github.com/llvm/llvm-project/commit/2e4d2d800b9ce0924513a2f24e7a1f3d22b52383) might have led to the same memory issues: https://lab.llvm.org/buildbot/#/builders/168/builds/15163

Add '#if SANITIZER_GLIBC' guards to avoid breaking FreeBSD

In D154272#4479087, @brooks wrote:

This change broke the build of msan on FreeBSD. dladdr1 seems to be a glibc-ism and is not present in FreeBSD or musl. All this functionality needs to be gated by a CMake check.

Fix 'cast from 'void ' to 'const Elf64_Sym ' must have all intermediate pointers const qualified to be safe [-Werror,-Wcast-qual]'

Made 'if (! map) return;' change

Fix null pointer case
Add license to top of header files

Change order of headers

Refactor

"#include <dlfcn.h> and friends in a cpp file and export function like UnpoisonDllAddr1ExtraInfo"

Refactor into UnpoisonDllAddr1ExtraInfo(), per Vitaly's suggestion

Adds a new header file, msan_dl.h, per Vitaly's suggestion.

What is the use case for this? If sanitizers other than TSan haven't needed to intercept munmap, adding it to sanitizer-common seems to just be adding overhead and possible complications.

edit: Craig beat me to it :-)

Remove unnecessary braces

In D151514#4374439, @philnik wrote:

See D151508

For readability, change CHECK(tag == 0) to CHECK_EQ(addr, UntagPtr(addr));

clang-format'ed

The libcxx tests might also need updating:

Disallow MAP_FIXED with a tagged pointer, which is an odd usecase. This simplifies the code greatly, since an invariant
is that mmap will no longer return any tagged pointers, hence there is no need to intercept munmap.

Changed mmap interceptor to use tagging only if given a tagged address plus MAP_FIXED.

In D144394#4373206, @philnik wrote:

In D144394#4373150, @thurston wrote:

I think this might have broken one of the sanitizer buildbots:

https://lab.llvm.org/buildbot/#/builders/37/builds/22340

+ diff -u /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/sanitizer_common/symbolizer/scripts/global_symbols.txt undefined.new
+wmemchr U
+ echo 'Failed: unexpected symbols'

(it might just need to have that line added?)

Yeah, that looks like a compiler-rt thing. I guess they check which symbols they rely on (and apparently now they rely on ẁmemchr`). Given that wmemcpy, wmemmove and wmemset are also listed there, it's probably fine to add wmemchr.

I think this might have broken one of the sanitizer buildbots:

In D150577#4372817, @bjope wrote:

In D150577#4372783, @thurston wrote:

https://reviews.llvm.org/rGa23f9846163956b74ab578bc972415c015022d10
added llvm/unittests/CodeGen/MachineBasicBlockTest.cpp
which is leading to uninitialized memory errors:

https://lab.llvm.org/buildbot/#/builders/239/builds/2416

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0xaaaad2ec0254 in operator new(unsigned long) /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:95:3
    #1 0xaaaad821b360 in operator new /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/lib/IR/Metadata.cpp:531:40
    #2 0xaaaad821b360 in llvm::MDTuple::getImpl(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>, llvm::Metadata::StorageType, bool) /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/lib/IR/Metadata.cpp:937:20
    #3 0xaaaad800a32c in getTemporary /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/IR/Metadata.h:1395:24
    #4 0xaaaad800a32c in llvm::DIBuilder::createFunction(llvm::DIScope*, llvm::StringRef, llvm::StringRef, llvm::DIFile*, unsigned int, llvm::DISubroutineType*, unsigned int, llvm::DINode::DIFlags, llvm::DISubprogram::DISPFlags, llvm::MDTupleTypedArrayWrapper<llvm::DITemplateParameter>, llvm::DISubprogram*, llvm::MDTupleTypedArrayWrapper<llvm::DIType>, llvm::MDTupleTypedArrayWrapper<llvm::DINode>, llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/lib/IR/DIBuilder.cpp:854:7
    #5 0xaaaad30c3a8c in (anonymous namespace)::FindDebugLocTest_DifferentIterators_Test::TestBody() /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/unittests/CodeGen/MachineBasicBlockTest.cpp:47:11
    #6 0xaaaad90750e0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/third-party/unittest/googletest/src/gtest.cc

(this was the closest Differential revision I could find for this file)

Thanks!
I've actually been working on a fix (struggled a bit to verify it since I'm not so used to running single unittests with asan, so it took some time to rebuild/rerun all tests using asan).
But I've pushed a fix now that hopefully should work: https://reviews.llvm.org/rG28d418b16c6cd4836ad9d8bc8006d3dabe3c5559

https://reviews.llvm.org/rGa23f9846163956b74ab578bc972415c015022d10
added llvm/unittests/CodeGen/MachineBasicBlockTest.cpp
which is leading to uninitialized memory errors:

I see, thanks Marco for the quick reply!