What does the DWARF information generated by your GHC branch look like?

[Peter Wortmann]

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