DWARF Standard


HOME
SPECIFICATIONS
FAQ
ISSUES



040909.1 Alasdair Grant DW_AT_default_value Extension Accepted with modification Matthew Gretton-Dann


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". 


All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.