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

[David Blaikie]

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.

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

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