<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<p>My goal was reducing the size of .debug_info, however 158009 did not achieve this</p>
<p>and I was trying to eliminate the bloat that it caused.</p>
<p> </p>
<p>If the artificial entries are useful for some other purpose then reverting 158009 is fine.</p>
<p>If we do that, then my patch #1 becomes unnecessary. Depending on what we decide</p>
<p>'nodebug' means, patch #2 may also be unnecessary, although I observe that there</p>
<p>really are no tests for 'nodebug' on a method and we might want to hang onto that part.</p>
<p> </p>
<p>> What I don't need is the debug info for bodies of these functions (all the local variables</p>
<div>> etc.).</div>
<p> </p>
<p>When we are talking about class methods, what happens is that there is a declaration</p>
<p>DIE which is a child of the class DIE. This DIE has no code range. When the method is</p>
<p>defined, there is a definition DIE with code ranges, and DW_AT_specification pointing</p>
<p>back to the declaration DIE. (The problem with 158009 is that there was no declaration</p>
<p>DIE, so Clang created one on the fly.) So, if you are thinking of suppressing the</p>
<p>definition DIE, you won't get code ranges for the artificial methods. This is already</p>
<p>the case for 'nodebug' methods, there is a declaration DIE but no definition DIE.</p>
<p> </p>
<p>I think this dual-DIE scheme does not apply to standalone functions. It looks like there</p>
<p>is no DIE at all for 'nodebug' standalone functions.</p>
<p> </p>
<p>I think most artificial functions/methods don't really have a lot of child DIEs? They are</p>
<p>usually pretty straightforward and don't declare local variables and so forth. For an</p>
<p>artificial constructor, if there is a DIE at all, you _do_ want to preserve the formal-parameter</p>
<p>DIEs, but that's about all you get anyway.</p>
<p> </p>
<p>So if you want definition DIEs, but no children (other than parameters), maybe for the</p>
<p>artificial/nodebug methods/functions we want to generate the declaration+defintion DIEs</p>
<p>but then treat the bodies as if we have -gline-tables-only in effect? Would that put the</p>
<p>right code ranges on the subprogram DIEs?</p>
<p>--paulr</p>
<p> </p>
<p>P.S. offsite the rest of the day, will try to check back this evening.</p>
<p> </p>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF508386"><font color="#000000" size="2" face="Tahoma"><b>From:</b> Alexey Samsonov [samsonov@google.com]<br>
<b>Sent:</b> Wednesday, October 17, 2012 9:39 AM<br>
<b>To:</b> Eric Christopher<br>
<b>Cc:</b> Robinson, Paul; cfe-commits@cs.uiuc.edu<br>
<b>Subject:</b> Re: [cfe-commits] [PATCH] PR14097, no debug info for artificial/'nodebug' methods<br>
</font><br>
</div>
<div></div>
<div><br>
<br>
<div class="gmail_quote">On Wed, Oct 17, 2012 at 7:57 AM, Eric Christopher <span dir="ltr">
<<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">> Yes it looks like our patches are at cross-purposes.<br>
><br>
> I assume that your patch gets the desired effect because there is now a DIE that<br>
> points to the subprogram's generated code? That's not good for me, because if<br>
> there's a class method definition DIE, it insists on having a declaration DIE too.<br>
> I'm not sure whether the same is true for standalone functions.<br>
><br>
> I wonder if there is a way we could produce an artificial subprogram DIE, but then<br>
> have LLVM not actually emit it to the DWARF. That is, suppress the excess DWARF<br>
> in LLVM rather than in Clang. If lives long enough to build the address ranges (and<br>
> also .debug_line?) it would meet your needs, and then if it doesn't actually get emitted<br>
> to .debug_info, it would meet my needs.<br>
</div>
</blockquote>
<div><br>
</div>
<div>What are your needs? Do you want to keep the .debug_info smaller, or this DIE may</div>
<div>be malformed and cause problems for you? I'm somewhat afraid that data in</div>
<div>.debug_line would not be enough for me. This depends on the way a tool maps</div>
<div>instruction address to compile unit. One of the way is:</div>
<div>1) get the compile unit DIE</div>
<div>2) get a DWARF line table for this DIE</div>
<div>3) parse the table and build address ranges for this compile unit.</div>
<div><br>
</div>
<div>This (step 3) is of course inefficient.</div>
<div>Currently LLVM's DebugInfo lib does the following:</div>
<div>1) get the compile unit DIE</div>
<div>2) get all subprogram DIEs for this CU</div>
<div>3) collects address ranges for these subprograms.</div>
<div><br>
</div>
<div>So, for such an approach, I need the debug_info entries for artificial functions and methods.</div>
<div>generated by Clang. I even may need entries for functions with disabled debug</div>
<div>info. What I don't need is the debug info for bodies of these functions (all the local variables</div>
<div>etc.).</div>
<div><br>
</div>
<div>Probably the best way is to use .debug_ranges section and add</div>
<div>a single DW_AT_ranges into the compile unit DIE. In this way we'll be able</div>
<div>to get all the instruction address ranges for compile unit without scanning any</div>
<div>additional DIEs (or using weird .debug_aranges section).</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im"><br>
</div>
I'm more than happy to revert r158009, I originally added it to reduce<br>
the amount of debug information since often people would not be trying<br>
to add break points or debug through an artificial function. Alexey's<br>
patch and motivation, however, lead me to believe that this was<br>
originally incorrect as we may want a backtrace with information and<br>
line numbers that includes artificial functions like global<br>
constructors.<br>
<br>
Either of you have an argument against reverting it?<br>
</blockquote>
<div><br>
</div>
<div>I have not.</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span></blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Alexey Samsonov, MSK</div>
<br>
</div>
</div>
</div>
</body>
</html>