A KMSAN_TYPE_STACK origin points at the string the compiler passed to
__msan_poison_alloca() to describe the variable. The reporting code
recognized only the format older versions of clang emitted,
"----var@function", and it checked for that only after trying
linker_ddb_search_symbol_name(). Neither part works with the compiler
we build with now:
- clang no longer prefixes the description or appends the function name. MemorySanitizer's poisonAllocaKmsan() passes getLocalVarDescription(), which is just the alloca's name, so the "----" comparison never matches and the variable name is never printed.
- the symbol search is tried first and effectively always "succeeds", since the origin address lies in .rodata and the search returns whatever unrelated symbol happens to precede the string. Every stack-variable report was therefore attributed to a meaningless symbol+offset, which is worse than saying nothing at all.
Add kmsan_orig_descr(), which makes no assumption about the format and
copies out whatever printable string is at the origin, and try it before
the symbol search. It fails cleanly when the origin holds a code
address rather than a description, so the symbol search still handles
the other origin types.
While here, include the size and the address in reports for memory that
has no recorded origin at all. That is all the information available in
that case, and it is often enough to identify what the memory is.
Sponsored by: Netflix
Assisted-By: Claude Code - Opus 5 (1M context)