On Wed, Sep 17, 2025 at 05:56:17PM +0000, Qing Zhao wrote: > Hi, > > > On Sep 13, 2025, at 19:23, Kees Cook <[email protected]> wrote: > > > > To support the KCFI typeid and future type-based allocators, > > Could you please explain a little bit more on the “future type-based > allocators”?
Sure, here's a link to Marco Elver's work: https://lore.kernel.org/lkml/[email protected]/ The "alloc token" is a bit more complicated: https://github.com/melver/llvm-project/blob/alloc-token/clang/docs/AllocToken.rst but my proposed __builtin_typeinfo_hash would align with mode=2 in the Clang proposal. > And why these two new builtins are necessary for this purpose? Andrew didn't want strings produced when they were unused so I needed a second API for getting string names. In either case, the result needed to be compile-time constant. Also, I wanted to mirror the existing C++ typeinfo API that has "hash" and "name" accessors separate. > > which need > > to convert unique types into unique 32-bit values, add a mangling system > > based on the Itanium C++ mangling ABI, adapted for for C types. > > There is a redundant “for” in the above last sentence. Oops! Fixed. > > Introduce > > __builtin_typeinfo_hash for the hash, and __builtin_typeinfo_name for > > testing and debugging (to see the human-readable mangling form). > > In addition to the testing and debugging purpose, are there any use cases for > these two new compiler provided builtins? For _hash, yes, using it for type-based compile-time constant values provides a building block for having type-aware logic in Linux, especially with the allocator. For _name, it's a nice way to get at the typeinfo for getting a stable string (right now there is no way to use typeof() output for any reporting). -- Kees Cook
