Issue 250407.1: Associating allocator call sites with type information

Jann Horn

## Background

If it was possible to query the DWARF type of a heap-allocated object
given its address, or list the addresses of all heap objects with a
given DWARF type, that would be useful for various use cases:

 - Most obviously for heap profiling ("how many objects of type X are
there, and what do their contents look like").
 - For associating Intel PEBS / AMD IBS hardware performance events
related to data caches with type information (answering questions like
"for this struct type, how often is each member accessed, and which
members are often cache-cold on access").
 - For associating memory access traces with type information.
 - Maybe for adding type information to ASAN use-after-free reports.

Some memory allocators already have support for recording from where
the allocator was called for each object; either by saving the
instruction address from which the allocator was called (with
`__builtin_return_address(0)`, for example in the Linux SLUB allocator
with `SLAB_STORE_USER`), or by saving an entire stack trace (for example
in ASAN).

The missing link for associating a heap object with a DWARF type is a
link between the callsite address and the DWARF type.

LLVM IR and Microsoft CodeView debuginfo already have this feature;
LLVM IR calls it "`heapallocsite`", CodeView calls it "`S_HEAPALLOCSITE`".
I think it makes sense to choose a similar name in DWARF
("`DW_AT_heapallocsite`"). An alternative that more closely aligns with
DWARF conventions might be something like "`DW_AT_call_allocated_type`".

A compiler might sometimes only have unreliable indicators of the type
of an allocation (like when `malloc()` is called with a size argument
derived from `sizeof()` in a non-trivial way), so I think the compiler
should be allowed to make a reasonable guess when no reliable type
information is available.

The attribute would primarily be used for calls to subroutines that
allocate individual objects (like C++ `new` or C `malloc()`); but it
might also be used, for example, when calling a subroutine that sets
up a type-specialized allocator instance (like
`__kmem_cache_create_args()` in Linux).

I expect the attribute to mostly be attached to `DW_TAG_call_site` in
practice, so that recording the return address in the allocator is
sufficient. However, it could work similarly with
`DW_TAG_inlined_subroutine` if the allocator records the current
instruction pointer when it is inlined.

If an allocator subroutine is expected to reliably record type
information with this mechanism, the compiler will probably have to
disable tail calls and, depending on implementation, also inlining for
calls to the allocator subroutine.

## Overview

Author:	Jann Horn
Champion:	David Blaikie
Date submitted:	2025-04-07
Date revised:	2025-05-13
Date closed:	2025-06-23
Type:	Enhancement
Status:	Accepted
DWARF version:	6