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

[David Blaikie]

-rsmith at chromium (which doesn't exist)
+rdsmith at chromium (which hopefully does exist)

On Sun, Aug 17, 2014 at 12:56 PM, David Blaikie <dblaikie at gmail.com> wrote:
> Sounds like someone else decided they wanted it too:
> http://llvm.org/bugs/show_bug.cgi?id=20690 (+bug filer, for his
> context)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42959 might have some
> relevant context/proposals/ideas/etc - including some points about the
> default argument expression needing to be evaluated in the context of
> the caller (I can't confirm/deny that - but an interesting thought,
> would have to check the C++ spec for wording there) in which case
> that'd be extra hard to encode this in a DWARF expression. Similar
> suggestions about using string for complex expressions.
>
> On Fri, Aug 15, 2014 at 10:27 PM, Frédéric Riss <friss at apple.com> wrote:
>>
>>> On 16 Aug 2014, at 03:18, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
>> […]
>>>>
>>>> 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!)
>>
>> I’m really not sure about that. Of course, when you think about it, it’s the first thing that comes to mind, default value expressions represented as DWARF expressions. However, C++11 allows nearly any expression as default value, and DWARF expressions are far from having the expressiveness required to represent the full range of allowed values. We could try to extend the representable expressions to allow more things, by e.g. adding target function calls to the DW_OPs, but that looks like a huge can of worms (Or this has already made it to DWARF5? I have only the version 4 spec handy right now.). It makes sense to allow DWARF expressions as an authorised form of DW_AT_default_value, but I think allowing a string representation of the source expression is unavoidable (and easier for me, I won’t deny that :-)).
>>
>>>>
>>>> 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).
>>
>> I’m not sure I understand what you mean. Are you suggesting to add a DW_OP_source_expression that would take a string as argument and evaluate it?
>>
>> Thanks for the feedback!
>> Fred
>>
>>> 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