Using using instead of typedef on the newly added ones.

Adding more isAligned DCHECK as Vitaly suggested.

Add stdlib.h to the test for posix_memalign. My builds don't
complain but I assume something will eventually.

In D103119#2822008, @yroux wrote:

Hi,

this is due to a misaligned data access, in Thumb the code generated for unmapTestOnly
contains a Vector Store instruction vst1.64 {d16-d17}, [r0, :128] which needs a 16-bytes
alignement, but the adress of TSDs (which is in r0) is not.

In D103119#2807183, @yroux wrote:

Hi,

This change introduced a regression on ARMv7 Thumb bots which wasn't noticed due to other issues.

logs can be seen here: https://lab.llvm.org/buildbot/#/builders/26/builds/2251

The 3 tests fail with a bus error raised from tsd_shared.h line 49

I patched it locally and everything passes for me.
Given the current timeline, I am OK with landing it now as is, and improve gradually on it.
I will pick up some of the action items, notably to try and reduce the memory footprint.

Was it the DCHECK issues I fixed with https://reviews.llvm.org/D103716 or something else?

In D103641#2799871, @cryptoad wrote:

In D103641#2799782, @kda wrote:

This looks like it broke the sanitizer-x86_64-linux-qemu.
https://lab.llvm.org/buildbot/#/builders/169/builds/501

Found the issue, testing the fix.

In D103641#2799782, @kda wrote:

This looks like it broke the sanitizer-x86_64-linux-qemu.
https://lab.llvm.org/buildbot/#/builders/169/builds/501

In rG868317b3fd765830c07ecf16cbfcf6c7708adc3c#1002135, @kda wrote:

This looks like it broke the sanitizer-x86_64-linux-qemu.
https://lab.llvm.org/buildbot/#/builders/169/builds/501

Switching 2 lines around.

Change type in vector test.

and I forgot to copy over the test file.

Remove InitialSize as suggested.

Remove stray comment.

Based on feedback, remove for now the CanGrow aspect of the vector.

In D103641#2797247, @hctim wrote:

CanGrow templated parameter that for now is
always true but would be set to false on Trusty.

Are we seeing OOMs on Trusty due to ScopedString? I had a quick look and it seemed like there's no non-ephemeral buffers (and really, this shouldn't be called very often at all), and it concerns me a little that push_back can silently fail on a ScopedErrorReport and truncate the text and it seems hard to test "all failure conditions log successfully".

Corrected, with a test now.

Correcting a couple of ScopedString constructors.

Thank you Daniel, this looks like a good start!
I'll work on my side on reducing some of the memory footprint of some structures and whatnot (scoped strings come to mind).
As discussed, we can re-introduce the use-separate-class-for-batches distinction for Trusty, which can be a large win to get rid of a class size.
I still think the Primary32 might be better suited here, but we'll follow up.

sanitizer-x86_64-linux https://lab.llvm.org/buildbot/#/builders/37/builds/4244 FAIL: ScudoStandalone-x86_64 :: preinit.c (772 of 856)
ppc64be-clang-test https://lab.llvm.org/buildbot#builders/52/builds/7794 TEST 'ScudoStandalone-powerpc64 :: preinit.c' FAILED
among others

I saw some bots failure for preinit.c:

FAIL: ScudoStandalone-i386 :: preinit.c (768 of 856)
******************** TEST 'ScudoStandalone-i386 :: preinit.c' FAILED ********************
Script:
--
: 'RUN: at line 1';      /b/sanitizer-x86_64-linux/build/clang_build/./bin/clang   -m32  -pthread -fPIE -pie -O0 -UNDEBUG -Wl,--gc-sections -resource-dir=/b/sanitizer-x86_64-linux/build/clang_build/./lib/clang/13.0.0/lib/linux/../../ -fsanitize=scudo /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/scudo/standalone/preinit.c -o /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/scudo/standalone/I386LinuxConfig/Output/preinit.c.tmp
: 'RUN: at line 2';    /b/sanitizer-x86_64-linux/build/clang_build/projects/compiler-rt/test/scudo/standalone/I386LinuxConfig/Output/preinit.c.tmp 2>&1
--
Exit Code: 139

Docs have been udpated some time ago with new build instructions to reflect the migration to the standalone version. Abandoning this.

I think Fuchsia doesn't need COMPILER_RT_HAS_AUXV since it's only used in Linux parts.

Remove HybridMutex::init, remove stray ;.

Right, that makes sense, thank you Vitaly!
FWIW, this was originally taken from CHECK_IMPL in sanitizer_common that seems to display the same behavior: https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h#L289

This might trigger sign-compare warnings like https://reviews.llvm.org/D103029?

ping please

Good point!

Shuffle a couple of lines around.

I should say that this improves the QPS for rpc2 benchmark in g3:

• New SCM: Finished measurement, throughput=438422.221084 reqs/sec.
• Old SCM: Finished measurement, throughput=421669.366002 reqs/sec.

Thank you Peter!

I think this is good, with the additional arch

I think one of the remaining things to address is the supported architectures:

set(ALL_SCUDO_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS32} ${MIPS64} ${PPC64})
set(ALL_SCUDO_STANDALONE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM64})

I am unclear as to whether or not there are consumers for the missing ones, but if there are we might break -fsanitize=scudo for them.
We have fallback for non-x86/arm processors in https://github.com/llvm/llvm-project/blob/e0921655b1ff8d4ba7c14be59252fe05b705920e/compiler-rt/lib/scudo/standalone/checksum.cpp#L79 , the rest looks fine so I think adding them should work.

Thanks a lot Mitch! Couple of comments from a first look, I'll give it another go later.

I should implement that someday, but nobody seems to have a need for it.

In D95884#2734462, @hctim wrote:

In D95884#2734450, @hctim wrote:

Update to provide correct statistics for live/free allocations in GWP-ASan. Use the slot size in the calculation rather than actual size, as there's no way to pre-calculate the size of the allocations that can land in the guarded pool.

@cryptoad - Just wanted to double check with you that this schema SGTY. mallinfo.uordblks and mallinfo.fordblks for malloc(1) moves up and down by a page if it lands in the GWP-ASan region, which is a little strange, but it's better than the alternative of having 4095 bytes "available" as noted by fordblks that aren't actually allocable.

ClassSize is only used for the stats in the local cache, what about initializing it to 0 for BatchClassId in initCache?

Right, it makes sense to not account for the batches. I don't think this should have a meaningful impact, but have you noticed any perf changes adding this since it's in the fastpath?

Is this related to the GWP-ASan initialization issues?
I am unclear if we need to rework the init() vs initLinkInitialized() functions as well?

Adding @hctim for visibility.

Thank you for finding this!
LGTM with a couple of nits

https://reviews.llvm.org/D100693 is better.

Well I wrote up https://reviews.llvm.org/D100683, but I guess yours makes more sense!

As far as I can tell this works.
With a few extra fixes:

[==========] 183 tests from 87 test cases ran (10944 ms total).
[  PASSED  ] 183 tests

In D100426#2689545, @vitalybuka wrote:

I assume D99766 should not be relevant because DefaultConfig is not tested on SCUDO_FUCHSIA ?