[Dwarf-Discuss] string reduction techniques

[Cary Coutant]

>> > I wouldn't be averse to considering what'd take to make DWARF robust enough to always roundtrip simple and linkage names in this way - I don't think it'd take a /lot/ of extra DWARF content.
>>
>> Fuzzy memory here, but as I recall, GCC didn't generate linkage names
>> (or only did in some very specific cases) until the LTO folks
>> convinced us they needed it in order to relate profile data back to
>> the source. Perhaps if we came up with a better way of doing that, we
>> could eliminate the linkage names.
>
> Yeah, fair - it's certainly what we use it for still, authoritative names for functions - including some amount of semantic information (so, for instance, I believe a hash is inadequate) which allows limited rewriting (when we changed standard libraries we were able to remap previous profile samples to line up with the new names (different inline namespaces, implementation names, etc) so as not to take a temporary perf hit as profiles were regenerated, etc).

Just dug up this little bit I wrote up for a "DWARF Best Practices"
wiki article:

The producer may also generate a DW_AT_linkage_name attribute for
program objects, but the presence of this attribute should never be
required to distinguish one program object from another. The DIE
hierarchy is able to provide qualifiers for the name, and the
DW_AT_name attribute itself provides template parameters. In the case
of overloaded functions, the DW_TAG_formal_parameter DIEs belonging to
the function DIE can provide the necessary information to distinguish
one overload from another. In many cases, however, it is expensive for
a consumer to parse the hierarchy, and the presence of the mangled
name may be beneficial to performance. In other cases, the producer
may choose to generate a limited subset of debug information, and the
mangled name may substitute for the missing information.

-cary