[all-commits] [llvm/llvm-project] 003ba4: [libc] Migrate `Block` to `BlockRef` in baremetal ...

[Schrodinger ZHU Yifan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 003ba404c8b50b367879cad29783d24881a6c1c6
      https://github.com/llvm/llvm-project/commit/003ba404c8b50b367879cad29783d24881a6c1c6
  Author: Schrodinger ZHU Yifan <yfzhu at google.com>
  Date:   2026-06-09 (Tue, 09 Jun 2026)

  Changed paths:
    M libc/fuzzing/__support/freelist_heap_fuzz.cpp
    M libc/src/__support/block.h
    M libc/src/__support/freelist.cpp
    M libc/src/__support/freelist.h
    M libc/src/__support/freelist_heap.h
    M libc/src/__support/freestore.h
    M libc/src/__support/freetrie.h
    M libc/test/src/__support/block_test.cpp
    M libc/test/src/__support/freelist_heap_test.cpp
    M libc/test/src/__support/freelist_test.cpp
    M libc/test/src/__support/freestore_test.cpp
    M libc/test/src/__support/freetrie_test.cpp

  Log Message:
  -----------
  [libc] Migrate `Block` to `BlockRef` in baremetal allocator (#201001)

Under C++ object lifetime and strict aliasing rules, accessing typed
objects requires that an object of that type actually exists at the
memory location. Previously, the Block structure stored prev and next
offset values, where the prev field overlapped with the usable space of
the preceding block to save space. When the predecessor was allocated,
user payload was written directly to this overlapping space,
complicating object lifetime management. A key issue arose during
reallocation (like in-place shrinking), where the allocator needed to
manipulate block boundaries (e.g., splitting a block) while user payload
was still actively residing in that memory. This caused undefined
behavior due to accessing typed Block members that collided with the
user's active objects.

This patch eliminates the problem by always treating blocks as raw bytes
accessed through a byte-backed proxy (BlockRef). Instead of constructing
or casting to typed Block structures, metadata is read and written using
aligned byte-copy operations (inline_memcpy). This decouples block
manipulation from C++ object lifetime rules, guaranteeing safe access
without violating strict aliasing.

Assisted-by: AI Tools, checked manually



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications