||Accepted with modification
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.
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".