<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2099327145;
mso-list-type:hybrid;
mso-list-template-ids:-909507594 1548275830 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:3;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>4) pointer size - it's specified by the CU header, but not in the line table header<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">(beats head on table) gotta have that to interpret DW_LNE_set_address correctly, afaict that's the *only* reason .debug_line would need it. Feh. But basically
you always need that, just to get started.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>5) inlining info<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For conjuring up fake frames in the traceback, presumably? That sort of thing always felt like the debugger was lying to me, personally.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:dblaikie@gmail.com]
<br>
<b>Sent:</b> Wednesday, April 29, 2015 3:33 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Greg Clayton; Eric Christopher; Eric Christopher; David Blaikie; Alexey Samsonov; cfe-dev@cs.uiuc.edu Developers<br>
<b>Subject:</b> Re: [cfe-dev] rfc: Adding a mode to -gline-tables-only to include parameter names, namespaces<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Apr 29, 2015 at 3:23 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">> -----Original Message-----<br>
> From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a>] On<br>
> Behalf Of Greg Clayton<br>
> Sent: Wednesday, April 29, 2015 1:55 PM<br>
> To: Eric Christopher<br>
> Cc: Eric Christopher; Alexey Samsonov; David Blaikie; <a href="mailto:cfe-dev@cs.uiuc.edu">
cfe-dev@cs.uiuc.edu</a><br>
> Developers<br>
> Subject: Re: [cfe-dev] rfc: Adding a mode to -gline-tables-only to include<br>
> parameter names, namespaces<br>
><br>
> Actually parameters and their types and locations would greatly help out.<br>
> This would increase debug info size, but it would also keep me from having<br>
> to detect borked DWARF and having to avoid parsing any of it in LLDB.<br>
> Right now the -gline-tables-only will quickly make LLDB assert and die if<br>
> we try to use this debug info because we try to convert a function into a<br>
> real clang::ASTContext type and clang will quickly assert and kill the<br>
> debug session when it becomes unhappy with us trying to create functions<br>
> with no params or return types (think "operator<" with no params... Boom.<br>
> Crash).<br>
><br>
> It is too bad that DWARF requires compile units just so we can have line<br>
> tables. If it wasn't for this, we could just emit a .debug_line section<br>
> with no .debug_info.<br>
<br>
Hmmm why was that, again? I can think of three possibilities, none of<br>
which should be insurmountable:<br>
1) CU has the base directory and filename of the compilation; .debug_line<br>
can include these directly, if we know it's -gline-tables-only.<br>
2) CU has the use_utf8 flag; just assume UTF-8.<br>
3) CU points to the chunk of .debug_line for this CU; we can probably<br>
work out how to reliably subdivide .debug_line without that assist.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
I don't think (3) is an issue - the line tables probably have their length in them.<br>
<br>
4) pointer size - it's specified by the CU header, but not in the line table header<br>
5) inlining info (this is pretty much the major point/issue with -gmlt) is not included in the line table. Cary's two-level line tables address this, though it's not implemented in LLVM. It's the minimal debug_info describing function inlining that's what confuses
LLDB.<br>
<br>
- David<br>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
Thanks,<br>
--paulr<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
><br>
> More comments inline below.<br>
><br>
> > On Apr 29, 2015, at 12:47 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Apr 29, 2015 at 12:41 PM Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
> > On Wed, Apr 29, 2015 at 12:35 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> > On Wed, Apr 29, 2015 at 12:25 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>><br>
> wrote:<br>
> > Hi,<br>
> ><br>
> > the motivation for -gline-tables-only was to make debug info much<br>
> smaller, but still include enough to get usable stack frames [1]. We<br>
> recently tried using it in Chromium and discovered that the stack frames<br>
> aren't all that usable: Function parameters disappear, as do function<br>
> namespaces.<br>
> ><br>
> > Are there any concerns about adding a mode to -gline-tables-only (or a<br>
> second flag -gline-tables-full, or similar) that includes function<br>
> parameter info and namespace info but still omits most debug info?<br>
><br>
> I would like this due to reasons mentioned above.<br>
> ><br>
> > (Background: We rely on dsym files to let our crash server symbolize<br>
> crash dumps we get from the wild. dsymutil uses debug info, but it<br>
> apparently crashes if debug info is > 4GB. We hit that recently. So we<br>
> started using -gline-tables-only, but now all our stacks are close to<br>
> unusable, even though the motivation for gline-tables-only was to still<br>
> have usable stacks. We can't easily use symbol names as they get stripped<br>
> very early in our pipeline, and changing that is apparently involved.)<br>
><br>
> You can still recover function bounds using the LC_FUNCTION_STARTS load<br>
> command even if you have a stripped executable. You won't have the<br>
> function names, but you can still backtrace and you can get accurate<br>
> function bound info for backtracing.<br>
><br>
> ><br>
> > Is there some way to change the pipeline to use the mangled name stored<br>
> in .symtab instead of the DW_AT_name in the DWARF? My understanding is<br>
> that the sanitizers already do this.<br>
><br>
> They probably just get the info from the symbol table.<br>
><br>
> ><br>
> > See "We can't easily use symbol names as they get stripped very early in<br>
> our pipeline." above – from what I understand, one machine does the build,<br>
> strips, runs dsymutil to get a .dSYM bundle, and then that is shipped to<br>
> the crash servers.<br>
><br>
> It better strip _after_ you run dsymutil to make the dSYM or you will get<br>
> empty dSYM files if the debug map is stripped. It really depends on what<br>
> kind of strip you are doing.<br>
><br>
> ><br>
> ><br>
> > (adding Greg for dsymutil issues, but I don't think there's much in the<br>
> way of solving it)<br>
> > Parameter names is something we could probably add. I'd like to see the<br>
> impact of it from a size perspective. I mean, next people will want<br>
> locations of parameters. Then... and we're right back to just full debug<br>
> info.<br>
><br>
> My main issue with -gline-tables-only (which LLDB doesn't support<br>
> currently due to the partial DWARF that is emitted that causes clang to<br>
> assert and kill the debugger) is that we now have DWARF that we can't<br>
> trust to use when creating types because all functions are potentially<br>
> invalid to create in a clang::ASTContext since everything has been<br>
> removed. Clang has the notion that certain types of functions must have<br>
> certain number of arguments, like C++ operators, and it gets unhappy if we<br>
> try to convert this DWARF into clang::AST types. We have a radar for clang<br>
> to somehow mark the debug info has "-gline-tables-only" so we can know<br>
> that any DW_TAG_subprogram tags we run into need to be converted to clang<br>
> AST types that return "UnknownAnyTy" and taking varargs as the parameters<br>
> so that they will be callable from the expression parser. We still might<br>
> run into names that can't be used as function names, especially if the<br>
> namespaces and class decl contexts are removed, so LLDB might have to just<br>
> say "I am not parsing any DWARF from anything that had -gline-tables-only<br>
> enabled..".<br>
><br>
> Greg Clayton<br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>