Johan Tibell wrote:
Do we follow the best practices here: http://wiki.dwarfstd.org/index.php?title=Best_Practices
Not quite sure what exactly you are referring to, here's the current state:
For DW_TAG_compilation_unit and DW_TAG_partial_unit DIEs, the name attribute should contain the path name of the primary source file from which the compilation unit was derived (see Section 3.1.1).
Yes, we do that.
If the compiler was invoked with a full path name, it is recommended to use the path name as given to the compiler, although it is considered acceptable to convert the path name to an equivalent path where none of the components is a symbolic link.
I am simply using ModLocation for this. The results make sense, even though I haven't tried crazy symbolic link combinations yet. If we find something to improve we should probably do it for GHC as a whole.
combining the compilation directory (see DW_AT_comp_dir) with the relative path name.
We set this attribute, albeit simply using getCurrentDirectory. This might be an oversight, but I couldn't see a location where GHC stores the "compilation directory" path.
For modules, subroutines, variables, parameters, constants, types, and labels, the DW_AT_name attribute should contain the name of the corresponding program object as it appears in the source code
We make a "best effort" to provide a suitable name for every single procedure. Note that a single function in Haskell might become multiple subroutines in DWARF - or not appear at all due to in-lining.
In general, the value of DW_AT_name should be such that a fully-qualified name constructed from the DW_AT_name attributes of the object and its containing objects will uniquely represent that object in a form natural to the source language.
This would probably require us to have a DIE for modules. Not quite sure how we would approach that.
The producer may also generate a DW_AT_linkage_name attribute for program objects
We do that.
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.
This might be the underlying reason why it shows mangled names for languages with unknown IDs (such as Haskell). We'll see whether Johan's query to the GDB team brings some light into that. Greetings, Peter Wortmann