DWARF Debugging Standard Wiki

THIS IS NOT AN OFFICIAL PROPOSAL AT THIS POINT IN TIME.

For a list of offical proposals and issues see : http://dwarfstd.org/Issues.php

For Chris’s working to-do list see : CQs To Do List

UPDATE

Based on my understanding that DW_AT_location and DW_AT_linkage_name shouldn’t be needed at the same time (for two different things) Ron Brender suggested using a new OP, like DW_OP_linkage_name inside a DW_AT_location expression to record this same information. This makes sense to me. But I am not 100% sure that gcc (or even suncc) doesn’t use both attributes for different data in the same tag. It would be a shame to standardize it and then find out it requires further dancing before it can be adopted by implementors.

But I still think it should be adopted as DW_OP_linkage_name without waiting for implementors (unless we find out that experimental implementations are imminent). The next step is to rewrite this draft proposal using DW_OP_linkage_name.

END UPDATE

There is an attribute DW_AT_MIPS_linkage_name which is used by gcc and g++ to record the external linker symbol for a subprogram. This is a vendor extension that’s been in use for a very long time and shared by multiple vendors.

I propose we create DW_AT_linkage_name as a standardization of the extension DW_AT_MIPS_linkage_name.

Sun uses something similar in cases where an address (IE a relocation) cannot be used to point at an external function or variable. In those cases, the compiler puts the mangled name into the dwarf data instead of the address of the function, and then the mangled name is looked up in the symbol table of the final a.out to find the address of the symbol.

In practice, it is impossible to reliably recreate the “mangled name” for a C++ symbol based on the type information recorded in dwarf. Even if it were possible it would require implementing a serious C++ compiler dependency (that is: the complete mangling algorithm) inside any dwarf consumer who wanted to look up the symbol in the ELF symbol table.

Commentary:

Dan Berlin said he was working to get rid of it in gcc, and I can say Sun is also trying to get rid of it wherever possible. (The problems are because of the space needed for the very long strings). But it turns out to be necessary in some cases.

I needed to add this to the Sun compilers in more cases when we’re trying to be “gdb friendly”. Assuming it’s removal from gcc is not imminent, I’d rather create a standard name for it, so we don’t have such a wide-spread use of a vendor extension which has essentially become a defacto part of the standard. If it one day goes away that’s fine. But I’d like to be able to document it as part of the standard so that people can understand it’s use better. (And we can point out the size issues related to its use).

We invented this at MIPS/SGI circa 1992 because we did not have a reliable demangler and we were transitioning from cfront to Edison front ends. And we were far from sure how to handle mangler-rules-transistions and far from sure how often mangler/demangler rules would change. At that time there was not much C++ code and the mangled names were not so long! So the space use was not too bad. (David Anderson)

dwarfstd.org is supported by Sourceware. Contributions are welcome. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2007-2022 by DWARF Standards Committee.