[RFC] Debuginfo: Add default value support for subprogram arguments

[Robinson, Paul]

> On Mon, Aug 18, 2014 at 11:14 AM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> >> From: David Blaikie [mailto:dblaikie at gmail.com]
> >> On Fri, Aug 15, 2014 at 6:18 PM, Robinson, Paul
> >> <Paul_Robinson at playstation.sony.com> wrote:
> >> >> The Dwarf standard reads:
> >> >>
> >> >> A DW_AT_default_value attribute for a formal parameter entry. The
> value
> >> of
> >> >> this attribute is a reference to the debugging information entry for
> a
> >> >> variable or subroutine, or the value may be a constant. If the
> >> attribute
> >> >> form is of class reference, the default value of the parameter is
> the
> >> value
> >> >> of the referenced variable (which may be constant) or the value
> >> returned by
> >> >> the referenced subroutine; a reference value of 0 means that no
> default
> >> >> value has been specified. If the value is of class constant, that
> >> constant
> >> >> is interpreted as a default value of the type of the formal
> parameter.
> >> >>
> >> >> For a constant form there is no way to express the absence of a
> default
> >> value.
> >> >
> >> > As a committee member I cringe at what the spec says here; you'd
> express
> >> the
> >> > absence of a default value by omitting the attribute, duh.
> >>
> >> I'm confused as to why this is cringeworthy - could you explain?
> >>
> >> Is it that, by defining the absence of a default value by the absence
> >> of the attribute, you can't express the case where you have a default
> >> argument whose value can't be expressed in DWARF? I imagine we'd want
> >> to do that by defining some attribute value to mean "no representable
> >> value" and still use the absence of the attribute to represent the
> >> absence of a default argument.
> >
> > "no default value has been specified" is different from "a default value
> > has been specified but DWARF is incapable of describing it."  Clearly,
> > if there is no default value at all, then the attribute should just be
> > omitted entirely.  That's not what the spec says.  Okay, maybe "cringe"
> > is going too far, but surely "wince" is appropriate.  :-)
> >
> > And if there is a default value (or any other construct) that DWARF is
> > incapable of describing, I think we are still better off omitting it
> than
> > providing an attribute that says "there's something in the source here
> but
> > I won't tell you what it is."  How could that possibly be useful?
> 
> Now I'm doubly confused. You seem to be agreeing that, if the default
> value cannot be described by DWARF, omitting the attribute entirely is
> probably reasonable because it's of limited value to the debugger to
> know that there's a default value, but not be able to describe/use it.

That is what I'm saying; I thought you were suggesting something else:

| I imagine we'd want to do that by defining some attribute value to mean
| "no representable value" and still use the absence of the attribute to
| represent the absence of a default argument.

but perhaps we are in violent agreement.

> 
> >> >> As you can see, this text limits us to emitting information about
> >> default
> >> >> values being:
> >> >> - simple constants (DW_FORM_data*)
> >> >> - global variable (DW_FORM_ref*)
> >> >> - calls to functions without arguments (DW_FORM_ref*)
> >> >
> >> > As written, yeah it does have that restriction.  Seems like more
> >> complicated
> >> > default-value computations could be handled with a DWARF expression,
> but
> >> > there's no provision in the spec for the attribute being an
> expression.
> >> > (Which doesn't stop you from inventing one; go right ahead!)
> >>
> >> Does the DWARF expression language provide the ability to express
> >> arbitrary source language expressions? I suppose it has a function
> >> call operation... addition, subtraction, etc... so not sure what we'd
> >> be missing, so maybe it is right.
> >
> > DWARF expressions are fully general within their domain, and in fact
> > DWARF 5 will likely introduce a "typed" stack making it easier to
> operate
> > on a variety of value domains; but, as Adrian mentioned elsewhere in the
> > thread, it does NOT include an operator that means "call this function
> in
> > the process being debugged."  So as long as your default value doesn't
> > require calling a function at runtime, you should be able to describe it
> > with a DWARF expression; but if it does require calling a function at
> > runtime, you're out of luck.  So, I was suggesting something beyond the
> > boundaries of what DWARF can provide, mea culpa.
> >
> >>
> >> That would mean providing a totally general purpose source->DWARF
> >> mapping in a compiler, which might be a bit much to ask.
> >
> > General purpose answer #1: That is a "quality of implementation" issue,
> > not a requirement. (Frederic has been proposing an expression string
> that
> > some sort of runtime evaluator would evaluate, and it's hard for me to
> > think that would be any less complicated.)
> 
> Seems less complicated to me - most debugger already has a source
> language expression evaluator, it's a common thing people want to do
> in debuggers. So it's very cheap to just ask it to evaluate another
> expression rather than implement a full source->DWARF compiler in
> every compiler (and DWARF->code JIT/compiler in every debugger).

For something that can be expressed as a DWARF expression, I think
that's preferable because it's a format that any DWARF consumer can
be expected to understand.  If you go beyond what DWARF can express,
some kind of string might be a reasonable vendor-extension fallback,
but not something that DWARF can reasonably specify.
--paulr

> 
> > --paulr
> >
> >>
> >> >
> >> >>
> >> >> I tried to go a bit further and implement a more complete solution
> that
> >> adds:
> >> >> - any link time constant (DW_FORM_block*): in this form, the block
> of
> >> data
> >> >> represents the default value as it would be stored in the target
> memory
> >> >> - arbitrary complex expressions (DW_FORM_str*): when no other of the
> >> above
> >> >> forms fits, this dumps the default value expression as textual form.
> >> The
> >> >> debugger can then evaluate this expression in the context of the
> >> declaration
> >> >> if it has this capacity
> >> >>
> >> >> First of all, would these kind of extensions be welcome? If you
> agree
> >> that
> >> >> they are worthwhile, I’ll submit a request to augment the standard
> >> wording.
> >> >
> >> > As I mentioned above, more complicated expressions should be
> expressed
> >> as
> >> > DWARF expressions, you just need to invent a way for the attribute to
> >> > reference the expression.  It's the end of a long week or I'd look up
> >> > some ways to do that for you (sorry).
> >> >
> >> > You are more than welcome to propose enhancements like this on the
> >> > DWARF website (dwarfstd.org).  The deadline for new features in DWARF
> 5
> >> > has passed, so it would be a while before it actually made it into a
> >> > published standard, but that gives you plenty of time for your
> >> > practical experience with implementing it!
> >> >
> >> > --paulr
> >> >
> >> >
> >> > _______________________________________________
> >> > llvm-commits mailing list
> >> > llvm-commits at cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits