... and remove local debugging line.

Addressing Mitch's request.

Thank you!

In rG45138f788c9b3c4ac5d9ae4479841c411c15190e#1020320, @rupprecht wrote:

Are you looking at resolving this build failure? Or maybe @cryptoad is?

I apologize, I messed up the revert of my other CL and this got reverted by mistake!

In D108089#2947081, @hctim wrote:

Side note - it'd be nice at some point if we can LSC all the use-of-custom-types away, any reason to keep them?

Redoing this the way Vitaly suggested.

So this turned out to be a little more complicated for 32-b.
The 'z' format specifier expects a size_t which is defined
as a unsigned int on 32-b Linux platforms, while our
scudo::uptr are defined a unsigned long. So zu wasn't
an appropriate specifier on 32-b platforms for a uptr.

In D106502#2895464, @sivachandra wrote:

@cryptoad - This adds a build level dependency across projects. Do you see any problems which this arrangement? We will also start testing this arrangement via integration tests on the LLVM libc buildbot workers.

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 ;.