There is no centralized store of information related to secondary
allocations. Moreover the allocations themselves become inaccessible
when the allocation is freed in order to implement UAF detection,
so we can't store information there to be used in case of UAF
anyway.
Therefore our storage location for tracking stack traces of secondary
allocations is a secondary ring buffer. The ring buffer is copied to
the process creating the crash dump when a fault occurs.
In order to support the scenario where an access to the ring buffer
is interrupted by a concurrently occurring crash, the secondary
ring buffer is accessed in a lock-free manner. This requires the
use of 128-bit atomics, which are generally only supported on 64-bit
platforms. Therefore the secondary ring buffer is disabled on 32-bit
platforms. The ring buffer would be unused on such platforms anyway
due to the lack of support for memory tagging on platforms other
than arm64.
This change enables 16-byte compare-exchange instructions on x86 in
order to avoid a warning where 128-bit atomics are used. Since the code
wouldn't actually be called in production on x86 as mentioned, this is
mostly in order to provide compile-time coverage and support fuzzing.
Depends on D93731
Does this actually do anything if all stores are relaxed?