<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<br class=""><br class="">This is an initial RFC regarding adding support for emitting default value debug information for function/method arguments. Although I’d appreciate initial review comments (patch attached), this is more about getting your feedback on the approach, as it diverges a bit from the standard.<br class=""><br class="">The Dwarf standard reads:<div class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">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.</div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">For a constant form there is no way to express the absence of a default value. </div></div><div class=""><br class=""></div></blockquote></div><div class=""><div class="">As you can see, this text limits us to emitting information about default values being:</div><div class=""> - simple constants (DW_FORM_data*)</div></div><div class=""> - global variable (DW_FORM_ref*)</div><div class=""> - calls to functions without arguments (DW_FORM_ref*)</div><div class=""><br class=""></div><div class="">I tried to go a bit further and implement a more complete solution that adds:</div><div class=""> - 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</div><div class=""> - 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</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The attached patches seems to get at least the basics right, but 2 issues are still bothering me:</div><div class=""><br class=""></div> - Forward declaration:<div class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">int foo();</div><div class=""><br class=""></div><div class="">void bar(int i = foo()) {return i;}</div><div class=""><br class=""></div><div class="">int foo() {return 1;}</div></blockquote><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">the default value references a forward decl of the function. When emitting the debuginfo metadata in CGDebugInfo.cpp:EmitDeclare(), the init function decl isn’t yet in the DeclCache. The current code falls back to emitting the default_value attribute as the “foo()” string. This is part of the basic stuff that could be expressed in standard Dwarf4, thus it would be nicer to have it emitted as a reference to foo’s DIE.</blockquote><br class="">- Relocatable address:</div><div class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">const char *me = “fred”;<br class="">void foo(const char *str = me);<br class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">the initialiser is a global address (function or data). The generated metadata is alright. If I have clang dump assembly, it looks fine. However, if I have clang emit the object file directly, it fails to relocate the address of the initialiser in the debug information. The ObjectStreamer adds fixups for the entries, but then nothing gets relocated. Any hints on how to debug that kind of failure?</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote></div><div class="">The final version of the patch will of course feature doc update and test(s).</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Fred</div><div class=""><br class=""></div><div class=""></div></body></html>