[Dwarf-Discuss] DW_AT_specification in C++ classes

Marcel Mettes marcelm@altium.nl
Mon Jan 28 12:50:28 GMT 2008


Hello,

We have three questions that all stem from the use of
DW_AT_specification in C++ class debug info constructs.

  1. Is this example a proper C++ class representation in DWARF?
  2. Is there an alternative representation available?
  3. Hide DIEs explicitly using a new attribute

1.Is this example a proper C++ class representation in DWARF
------------------------------------------------------------

We are considering cases where not 2 DIEs are used that are
connected via DW_AT_specification, but a chain of 3 DIEs.

Example:

    offset  DIE
    X1      DW_TAG_namespace
    X2      +- DW_TAG_class_type
    X3         +- DW_TAG_subprogram (at offset X3)
    X4            +- DW_AT_name "foo"

    ...

    offset  DIE
    Y1      DW_TAG_subprogram
    Y2      +- DW_AT_specification (points to (X3))

    ...

    offset  DIE
    Z1      DW_TAG_subprogram
    Z2      +- DW_AT_specification (points to (Y2))
    Z3      +- DW_AT_low_pc              value = 0x00000044
    Z4      +- DW_AT_high_pc             value = 0x0000004C
    Z5      +- DW_AT_frame_base          value = [location list]

This setup stems from the combining of all debug information from
the various stages along the tool-chain.

Is this an appropriate form to use for C++ class debug info?
We are wondering if already existing debuggers will be able to
both interpret it and use it.

2.Is there an alternative representation available?
----------------------------------------------------

Given the example in question 1 we are wondering if other debuggers
will be able to both interpret it and use it.

The 2 DW_AT_specification links may require extra code to be
added to existing debugger to convey the actual semantics of
the construct.

Hence we wonder, is there an already accepted or perhaps
even canonical form to represent C++ classes in DWARF 3 using
DW_AT_specification to construct class member debug info?  One that
can be interpreted by existing debuggers without
no or minor modifications?

3. Hide DIEs explicitly using a new attribute
---------------------------------------------

The use of DW_AT_specification brings with it the adding of DIEs
that have no meaning by themselves. However, if a linker happens
to place a DW_AT_name inside such an augmentation DIE, it may
show up as symbol in the debugger symbol browser, even though it
is not a symbol.

One could use the presence of DW_AT_spefication as a flag telling
to hide that DIE. Sort of like DW_TAG_imported_unit" (which is
described in Section 3.1.2 as "merely glue"), but for individual
tags? Or is DW_AT_specification supposed to be that glue?

This is not possible we think, since DW_AT_specification is also
used for linking e.g. C variable declarations to the real, global,
variable (see DWARF 3, par. 4.1, sub 6). In those cases the DIE
containing the DW_AT_specification must not be hidden in order to
enable the debgger to find that symbol in the scope it is in.

One can use the assumption that in all DIEs, except DIEs
with DW_TAG_variable/DW_TAG_formal_parameter/DW_TAG_constant,
the presence of an DW_AT_specification is to be interpreted as
marking the DIE as hidden, but that is not clearly stated as such
in the DWARF 3 definition. Hence it may change in the future which
TAGs/DW_AT_specification combinations are hidden or not.

One can look at the DW_AT_specification DIEs as augmenting DIEs,
provided to enable implementors of compilers, assemblers and
linkers to pour the debug info into DWARF form, by combining them
via DW_AT_specification from multiple sources, into a meaningful
set of DIEs.

The question we have is: is it perhaps possible to flag DIEs that
are only used to augment other, defining, DIEs as hidden with an
attribute specific for this task?

Best regards,
Marcel Mettes

********************************************
Altium - Unified PCB/FPGA/C/C++ EDA Tools
http://www.altium.com
********************************************






More information about the Dwarf-discuss mailing list