Issue 040909.1: DW_AT_default_value

Author: Alasdair Grant
Champion: Matthew Gretton-Dann
Date submitted: 2004-09-09
Date revised:
Date closed:
Type: Extension
Status: Accepted with modification
DWARF Version: 3
Sep 9, 2004 Alasdair Grant raised the issue:

Is there a reason why DW_AT_default_value needs to be restricted
to pointing to a debugging information entry for a variable or
subroutine [4.1], and not, say, DW_TAG_constant or DW_TAG_enumerator?
Even an inline constant would seem reasonable here.

David Anderson replied:

Al Grant asks:
>Is there a reason why DW_AT_default_value needs to be restricted
>to pointing to a debugging information entry for a variable or
>subroutine [4.1], and not, say, DW_TAG_constant or DW_TAG_enumerator?
>Even an inline constant would seem reasonable here.

I don't recall why the wording is
as specified, but note that the notion of 'variable' encompasses
variables that are compiler generated (DW_AT_artificial)
and have constant value.

This attribute refers to 'something', so I don't see
how DW_AT_default_value could 'be' a constant itself. ??


A concrete inlined instance with a constant value is
representable with bullet item 10 of 4.1, right?

Alasdair Grant expanded:

Yes, it wouldn't be much use for the purpose if it didn't!
My concern is efficiency.

> This attribute refers to 'something', so I don't see how
> DW_AT_default_value could 'be' a constant itself. ??

It could be a constant if it had form class 'constant' as an
alternative to its form class 'reference'.  For something like
the C++ function declaration

  int f(int n = 0);

it seems bizarre to have to invent an unnamed variable, or
even an unnamed constant, simply to represent the value 0
which could be encoded as e.g. DW_FORM_udata.

> A concrete inlined instance with a constant value is
> representable with bullet item 10 of 4.1, right?

Not necessarily - item 10 covers items whose value is 'not
represented by an object in the address space of the program'
and 'does not have a location attribute', which makes it not
generally applicable to formal parameters in, say, C++, which
are addressible objects with locations, unless optimized away.

> Am I missing something here?

As regards the representation of parameter defaults, I think
you are missing efficiency considerations.  It is inefficient
to have to encode a simple constant via a reference to an
unnamed artificial constant-valued variable.  DWARF seems
technically quite capable of encoding it as a constant.
Other attributes, such as type properties (2.18) have form
classes 'block, constant, reference'.  This would seem equally
appropriate for DW_AT_default_value.



PROPOSAL:

4.1, paragraph numbered 9 on DW_AT_default value be
altered to read:

9. A formal parameter entry may have a DW_AT_default_value
attribute. The value of this attribute  may be a reference to the
debugging information entry for a variable or subroutine, or
the value may be a constant value. If it is a reference, the
default value of the parameter is the value of the variable
(which may be constant) or the value returned by the
subroutine. If the value of the DW_AT_default_value reference attribute
is 0, it means that no default value has been specified.
If the value is of form constant, the type of the constant
must match the DW_AT_type of the formal-parameter-entry
(unlike with a reference form, with a constant forme
there is no means to indicate 'no default value').


Accepted, with change to read "a value of the same type 
as the formal parameter".