fix(aspacem): raise amd64 managed address ceiling to 1 TiB

snmalloc-rs as a global allocator aborts under Callgrind because its
startup mmap of a flat 256 GiB MAP_NORESERVE range returns EINVAL. On
amd64-linux the address-space manager capped the managed range at 128
GiB, placing vStart (the client/Valgrind split) at ~64 GiB, so the
largest floating client hole was ~62 GiB and any larger reservation was
vetoed by VG_(am_get_advisory).

Raise aspacem_maxAddr to 1 TiB (vStart ~512 GiB, ~512 GiB client hole),
scoped to VGP_amd64_linux so other 64-bit ports keep 128 GiB (some arm64
kernels expose only a 39-bit user VA). No effect on Callgrind placement
semantics; the fork ships only the 64-bit Callgrind tool.

Refs COD-3073

Author: not-matthias

CODSPEED-CHANGELOG.md

@@ -113,3 +113,24 @@ valgrind --tool=callgrind \
     --obj-skip=/lib/x86_64-linux-gnu/libpthread.so.0 \
     ./your_program
 ```
+
+## Changes
+
+### Raise amd64 managed address-space ceiling to 1 TiB
+
+**Change**: On `amd64-linux`, the address-space manager's ceiling (`aspacem_maxAddr`) is raised from 128 GiB to 1 TiB.
+
+**Motivation**: Allocators that reserve a single large, lazily-backed (`MAP_NORESERVE`) address range at startup aborted under Valgrind. The concrete case is `snmalloc` (used via `snmalloc-rs` as a global allocator), which reserves a flat 256 GiB range on init:
+
+```
+sys_mmap( NULL, 274877906944, PROT_READ|WRITE, MAP_PRIVATE|ANON|NORESERVE, -1, 0 ) --> EINVAL
+"Failed to initialise snmalloc." -> SIGABRT
+```
+
+A real kernel grants this for free (virtual only). Valgrind's aspacem, however, only manages a bounded region and rejects a floating request that cannot fit. With the old 128 GiB ceiling, `vStart` (the client/Valgrind split) sat at ~64 GiB, so the largest contiguous client hole was ~62 GiB and any reservation above that returned `EINVAL`, forcing the CodSpeed wizard to fall back to walltime instead of simulation mode.
+
+**How it works**: `aspacem_vStart` is the midpoint of `[minAddr, maxAddr]` and a one-page reservation is placed there at startup, so a floating client `mmap` (which searches upward from `cStart`) can obtain a contiguous hole of at most ~half the ceiling. A 1 TiB ceiling yields a ~512 GiB client hole, which accommodates the 256 GiB reservation with headroom. 1 TiB stays well within amd64's 47-bit (128 TiB) user address space.
+
+**Scope**: The change is guarded by `defined(VGP_amd64_linux)`; other 64-bit Linux ports keep the 128 GiB ceiling (some arm64 kernels expose only a 39-bit / 512 GiB user VA, which a 1 TiB ceiling would exceed). The raised ceiling also moves the client's initial stack and Valgrind's own segments to higher addresses. This has no effect on Callgrind (no per-address shadow map); Memcheck would service the now-higher stack via its slower auxiliary map, but the CodSpeed build ships only the 64-bit Callgrind tool.
+
+**Workaround (no fork change)**: Building `snmalloc-rs` with its `qemu` feature (`SNMALLOC_QEMU_WORKAROUND`) drops the reservation to 32 GiB, which fits the old 128 GiB layout.

coregrind/m_aspacemgr/aspacemgr-linux.c

@@ -1862,7 +1862,17 @@ Addr VG_(am_startup) ( Addr sp_at_startup )
                     sp_at_startup );
 
 #  if VG_WORDSIZE == 8
+#    if defined(VGP_amd64_linux)
+     // Startup inserts a one-page reservation at vStart (the midpoint of
+     // [minAddr, maxAddr]), splitting the initial free space. A floating
+     // client mmap searches upward from cStart, so the largest contiguous
+     // hole it can get runs up to that split, i.e. ~half of maxAddr. 128G
+     // left only a ~64G client hole, rejecting multi-hundred-GB lazily-backed
+     // reservations. 1T gives a ~512G hole, well within amd64's 47-bit VA.
+     aspacem_maxAddr = (Addr)0x10000000000ULL - 1; // 1T
+#    else
      aspacem_maxAddr = (Addr)0x2000000000ULL - 1; // 128G
+#    endif
 #    ifdef ENABLE_INNER
      { Addr cse = VG_PGROUNDDN( sp_at_startup ) - 1;
        if (aspacem_maxAddr > cse)