On Fri, Feb 28, 2014 at 4:53 PM, Austin Seipp wrote:

(Passive note - this conversation looks like Johan talking to himself, as I suspect Peter is not 'reply all'-ing to the developers list. So other people may be a tad lost.)

Nope, this is just me having a stream of consciousness discussion. If you see 2 replies from Peter and 5 emails from me (including this one), that's it. :)

On Fri, Feb 28, 2014 at 4:57 PM, Roman Cheplyaka wrote:

Or he's not subscribed to this list and his messages do not come through

Ah yes. From my end I can see that he tried to CC the mailing list, but I missed that the messages didn't get through.

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

Nathan Howell wrote:

I did get a language ID assigned a couple years ago, it should be in DWARF 5.

Accepted: DW_LANG_Haskell assigned value 0x18. -- April 18.2012

Nice work. We'll start using that one then :) Greetings, Peter Wortmann