<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On May 4, 2015, at 12:46 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" class="">Paul_Robinson@playstation.sony.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">From Fred:<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Source fidelity is not about emitting every declaration you see.<br class="">It's about, *if* you're going emit something, do it in a way that is<br class="">faithful to the source-as-written.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">and I’d add “gives means to the debugger to evaluate every source expression<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">as it is written in the source.” <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Agreed. But a 'using' declaration is not an expression. If the declared name is not used in any source expression, it can hardly be needed to evaluate a source expression as written in the source.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I admit calling this stuff "useless" is a bit of hyperbole. Clang is being inconsistent. If a normal unqualified function declaration isn't emitted, and a normal function declaration inside a namespace isn't emitted, I see no argument justifying emitting a function that happens to be declared with a 'using' declaration. A 'using' versus a normal declaration is typically an implementation detail, not something inherently significant that can change the meaning of a program.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a name="_MailEndCompose" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">The whole story is that I was working on getting debug info emitted<br class="">for function argument default values (which I haven’t gotten back to<br class="">yet BTW), and that my implementation didn’t work if the default value<br class="">was a call to a forward declared function. Our decl tracking didn’t<br class="">handle forward declarations at all, and David pointed out that this<br class="">was why we were also missing some DW_TAG_imported_declaration. I<br class="">then implemented support for forward declarations and tested it using<br class="">the the only current user that cared about forward decls, that is the<br class="">imported_declaration stuff.<br class=""><br class=""></span></a><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">But it looks to me like these "missing" imported_declarations aren't any more missing than the equivalent non-'using' declarations. Is there a principled justification for the inconsistency? I'm not hearing one. What I'm hearing is the Clang can't keep track of what's actually needed in the source, so we arbitrarily emit some things and not others when we're not sure. That's really unsatisfactory.</span></div></div></div></blockquote><div><br class=""></div><div>IIRC they were missing because even if the file contained a full definition afterwards, we wouldn’t emit it (as we’d ignored the fwd decl used in the using clause in the first place). The patch added support for forward definitions and for their coalescing with complete definitions (that’s the RAUW part you mention at some point).</div><div>I don’t think the situation is more unsatisfactory now than it was before. But sure, among the new debug info that we emit, you might consider some of it as useless.</div><div><br class=""></div><div>The thing I’m not seeing right now is what you are proposing to move the situation towards a more satisfactory state (i.e., that would keep the GDB regression going and meet your size goals).</div><div><br class=""></div><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Now, if the forward declaration bit is something that was part of a larger project that is half-implemented, and the imported_declaration bit was a momentary convenience that you intended to take out later, well that's fine so long as you now intend to finish the job.</span></div></div></blockquote><div><br class=""></div><div>Finishing the job on my initial project won’t change anything to the number of declarations that are emitted. If anything it would just add another user that might emit more function/variables declarations (these ones you might find more justified as they stem from a use of the declaration as default argument value).</div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I am sympathetic to the desire to have the full power of libc available in conditional breakpoints, and so forth. If that's your preferred mode then perhaps a more –gfull-to-bursting mode might be the ticket. If it didn't cost multi-megabytes to get there, and the time it takes to write all that out, and link it together, then I'd have no problem with always emitting everything. As it is, we seem to have at least two modes of not-emitting-everything, and the balance point of things-most-likely-to-be-useful doesn't really seem to warrant including "anything that the standard-library implementor decided to implement with a 'using' declaration.”</span></div></div></blockquote><div><br class=""></div><div>I think that never in this thread I argued against emitting less information. All I ever said is that:</div><div> 1/ The information is not as useless as you made it sound (and thus removing it entirely isn’t NFC)</div><div> 2/ It’s certainly sound to filter what clauses we want to emit, but if we wanted to filter it depending ‘use of the declaration’ someone would have to do the work because nothing like that exists in the code yet.</div><br class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">(Hmmm… could we suppress this stuff just for standard-header declarations? That's where our immediate pain-point seems to be.)</span></div></div></blockquote><div><br class=""></div><div>That might be feasible (the standard headers are undergoing special treatment, but I’ve got no idea if there is a ‘standard header’ flag still available when we process the declarations). I think it makes sense to collect more detailed information about application-level code as opposed to system-provided code.</div><div><br class=""></div><div>Fred</div><div><br class=""></div><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">--paulr<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span></div><div style="border-style: none none none solid; border-left-color: blue; border-left-width: 1.5pt; padding: 0in 0in 0in 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><b class=""><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class=""><span class="Apple-converted-space"> </span>David Blaikie [<a href="mailto:dblaikie@gmail.com" class="">mailto:dblaikie@gmail.com</a>]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Monday, May 04, 2015 10:56 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Frédéric Riss<br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>Robinson, Paul; <a href="mailto:cfe-dev@cs.uiuc.edu" class="">cfe-dev@cs.uiuc.edu</a> Developers (<a href="mailto:cfe-dev@cs.uiuc.edu" class="">cfe-dev@cs.uiuc.edu</a>)<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [cfe-dev] r222220 causes real debug-info bloat<o:p class=""></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On Mon, May 4, 2015 at 10:39 AM, Frédéric Riss <<a href="mailto:friss@apple.com" target="_blank" style="color: purple; text-decoration: underline;" class="">friss@apple.com</a>> wrote:<o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On May 4, 2015, at 9:51 AM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank" style="color: purple; text-decoration: underline;" class="">Paul_Robinson@playstation.sony.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt; text-align: start; word-spacing: 0px;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">-----Original Message-----<br class="">From: Frédéric Riss [<a href="mailto:friss@apple.com" target="_blank" style="color: purple; text-decoration: underline;" class="">mailto:friss@apple.com</a>]<br class="">Sent: Friday, May 01, 2015 6:34 PM<br class="">To: Robinson, Paul<br class="">Cc:<span class="Apple-converted-space"> </span><a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank" style="color: purple; text-decoration: underline;" class="">cfe-dev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span>Developers (<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank" style="color: purple; text-decoration: underline;" class="">cfe-dev@cs.uiuc.edu</a>)<br class="">Subject: Re: r222220 causes real debug-info bloat<br class=""><br class="">Hi!<br class=""><br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">On May 1, 2015, at 5:29 PM, Robinson, Paul<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank" style="color: purple; text-decoration: underline;" class="">Paul_Robinson@playstation.sony.com</a>> wrote:<br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">We were doing some size analysis and noticed some ridiculous numbers<br class="">related to debug-info size. Investigation showed that essentially all<br class="">of the bloat came from DW_TAG_imported_declaration pointing to<br class="">DW_TAG_subprogram and the associated DW_TAG_formal_parameter DIEs.<br class="">We tracked this to r222220, which basically caused every 'using' decl<br class="">of a function or variable to have a forward declaration emitted to the<br class="">DWARF, whether or not that 'using' decl itself was used in the CU.<br class=""><br class="">#include <stdlib.h><br class="">using ::abort<br class=""><br class="">In Clang 3.5, this produces a pretty minimal .debug_info section (just<br class="">the DW_TAG_compile_unit).<br class="">In Clang 3.6, we see an additional DW_TAG_subprogram for abort() and<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">then<br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">a DW_TAG_imported_declaration pointing to that declaration.<br class=""><br class="">#include <cstdlib><br class=""><br class="">on Linux, Clang 3.5 wrote a .debug_info of 185 bytes, 3.6 was 1458.<br class=""><br class="">Multiply this by more headers and again by hundreds to thousands<br class="">of modules and pretty soon you're talking multiple megabytes.<br class="">Getting away from the benchmarks, a real game saw .debug_info increase<br class="">by 13% (6 MB).<br class=""><br class="">r222220 basically causes a 'using' declaration of a function or global<br class="">variable to conjure up a forward declaration, if we haven't already<br class="">seen a declaration or definition. The commentary talks about how this<br class="">will be RAUW'd later on. But I'm not sure what motivated this in the<br class="">first place, and it clearly can have a huge adverse effect.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">The whole story is that I was working on getting debug info emitted<br class="">for function argument default values (which I haven’t gotten back to<br class="">yet BTW), and that my implementation didn’t work if the default value<br class="">was a call to a forward declared function. Our decl tracking didn’t<br class="">handle forward declarations at all, and David pointed out that this<br class="">was why we were also missing some DW_TAG_imported_declaration. I<br class="">then implemented support for forward declarations and tested it using<br class="">the the only current user that cared about forward decls, that is the<br class="">imported_declaration stuff.<br class=""><br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">I don't mind having a DW_TAG_imported_declaration for something that<br class="">actually gets used in the CU, but a 'using' declaration all by itself<br class="">should not count as "used" for purposes of emitting debug info.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">It’s not that the using clause counts as a ‘use’, it’s just a<br class="">question of source fidelity.<o:p class=""></o:p></span></div></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">Source fidelity is not about emitting every declaration you see.<br class="">It's about, *if* you're going emit something, do it in a way that is<br class="">faithful to the source-as-written.</span><o:p class=""></o:p></div></div></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">and I’d add “gives means to the debugger to evaluate every source expression<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">as it is written in the source.” <o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt; text-align: start; word-spacing: 0px;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Your above example isn’t really<br class="">compelling. By changing it a little bit to:<br class=""><br class="">#include <stdlib.h><br class=""><br class="">namespace A {<br class="">using ::abort;<br class="">}<br class=""><br class="">The goal of the imported_declaration information is to inform<br class="">the debugger that in this CU, A::abort is the same thing as<br class="">::abort. It’s just a matter of describing aliased name to<br class="">the debugger so that it can correctly evaluate source<br class="">expressions.<o:p class=""></o:p></span></div></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">Consider this:<br class=""><br class="">void abort();<br class="">namespace A {<br class="">#if USING<br class=""> using ::abort();<br class="">#else<br class=""> void abort();<br class="">#endif<br class="">};<br class=""><br class="">In the not-USING case, Clang emits nothing but the CU DIE, because<br class="">neither abort() declaration is used.<br class="">In the USING case, we see the imported_declaration and the associated<br class="">subprogram. In both cases, the set of declared names is the same, and<br class="">there are no *actual* uses of either name.</span><o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">I’m repeating myself, but this is not about uses, just about describing names.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Then, as a compiler policy, you might want to limit the names you describe<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">to the ones that are actually used in the program (we have no code to track<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">the uses and modify the debug info accordingly). You might also want to<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">emit all the names so that the debugger can evaluate accurately every<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">expression that could happen in the source code.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">I’m not arguing that one of the above is better than the other (the answer can<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">certainly be different depending on the environment), I mostly want to point<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">out that this information isn’t as useless as you seem to think.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Therefore, I argue, this is not about source fidelity but about<br class="">declining to produce declarations not useful to the consumer.</span><o:p class=""></o:p></div></div></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">David would need to confirm, but I think that if we revert the change, there<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">are tests in the GDB test suite that will fail.<o:p class=""></o:p></div></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class="">I don't recall precisely - but yes, I think we un-XFAIL'd some tests after you made this change. Could check.<br class=""> <o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-color: rgb(204, 204, 204); border-left-width: 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">‘Not useful’ information should not<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">be able to break user level tests, should it? <o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt; text-align: start; word-spacing: 0px;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Can somebody describe how these extra forward declarations fit into<br class="">the Grand Scheme of Things in a beneficial way, and can we do something<br class="">about unused 'using' declarations?<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">I totally get your point about the size, and according to past<br class="">conversations, I gather that the use described above isn’t maybe<br class="">relevant to your debugger (which maybe points to something that<br class="">can be tuned depending on the target debugger? I’m sorry, but I<br class="">just came back from a long leave and I’m so much behind on list<br class="">reading that I have no idea of the status of that idea).<br class=""><br class="">IMO, it has nothing to do with the fact that the function/variable<br class="">is used or not. The using directives create new names and the only<br class="">way for the debugger(s) to understand these names is to have them<br class="">described in the debug info.<o:p class=""></o:p></span></div></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">By that argument you should emit every name you see in every header,<br class="">whether it is used or not. That's not what we do, because it's not<br class="">useful to anyone and unnecessarily bloats the debug info. The case of<br class="">used-only-by-'using' is no different because there's no *actual* use.</span><o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">I’m sorry, but the fact that all declarations aren’t emitted happen to bother<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">me from time to time. I’m a heavy user of debugger conditional breakpoints,<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">and the conditions often involve calling to functions that aren’t defined in my<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">program, but which were described in the headers (for example libc).<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Not having the prototype for these functions available to the debugger requires<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">me to play casting games so that it gets the calling convention correctly. If all<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">the declarations were to be emitted I wouldn’t have that issue and my debug<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">experience would be better.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Do not get me wrong. I’m not arguing for including all the declarations. I’m just<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">trying to point out the the information isn’t useless as you describe it and that <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">there is a balance to find. Including only the names that have been really used<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">in the program would be a perfectly sensible one, but we do not have the code<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">that does that tracking!<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">I found it instructive to add this to my not-USING example:<br class=""><br class="">void foo() { ::abort(); A::abort(); }<br class=""><br class="">which naively I would expect to induce subprogram DIEs for abort() and<br class="">A::abort(), but in fact it doesn't, even with -fstandalone-debug. That<br class="">seems sub-optimal too. But, it just further illustrates the discrepancy<br class="">between the 'using' declarations and non-'using' declarations.<br class=""><br class="">Also that there's a deeper problem here, which might or might not be<br class="">what David Blaikie was getting at.<br class=""><br class="">The missing DIEs in the non-USING case, along with memories of trying<br class="">to do something else with used/non-used declarations some while ago,<br class="">make me think that even though abort() and A::abort() are (probably)<br class="">being flagged, debug-info generation isn't going back through those<br class="">non-defining declarations to see which ones ought to be emitted after<br class="">all.</span><o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">As pointed above, such code that goes from the uses to the debug info just<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">doesn’t exist. The debug info for types and declarations is generated during<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">AST construction (IIRC) and not touched afterwards.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Fred<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">It looks like CGDebugInfo::finalize() does a post-pass for types, to<br class="">some extent; maybe that needs to be done for other decls as well?<br class="">--paulr<br class=""><br style="text-align: start; word-spacing: 0px;" class=""><br class=""></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Given how the patch works, it looks we can just short-circuit the<br class="">creation of these forward declarations with no harm done, but I have to<br class="">wonder whether we're shooting ourselves in the foot in some situation<br class="">that isn't immediately obvious.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class=""><br class="">If the git commit message is still accurate regarding the use of that<br class="">function, then you’ll just go back to the previous state which you<br class="">liked better. If the function grows new callers, you might lose<br class="">more stuff, but IIUC it should mostly be stuff that you don’t care<br class="">about anyway.<br class=""><br class="">Fred<br class=""><br class=""><br class=""><br class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9pt; font-family: Helvetica, sans-serif;" class="">Thanks,<br class="">--paulr<o:p class=""></o:p></span></div></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@cs.uiuc.edu" style="color: purple; text-decoration: underline;" class="">cfe-dev@cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank" style="color: purple; text-decoration: underline;" class="">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></p></blockquote></div></div></div></div></div></blockquote></div><br class=""></body></html>