<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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Menlo-Regular;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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;}
span.m-7385754809470379542apple-converted-space
{mso-style-name:m_-7385754809470379542apple-converted-space;}
span.EmailStyle18
{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;}
--></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="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The Robustness Principle suggests we should tolerate whatever we reasonably can, even if we know that Clang itself would never produce such oddball DWARF.
We do have a long-term goal of having LLDB use LLVM's DWARF parser, and a debugger's parser needs to be *way* more tolerant than a compiler verification tool. While I can't say the DWARF spec rigorously defines what a chain of abstract-origin and specification
attributes means, intuitively it can be interpreted, so long as there aren't any cycles.<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"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Menlo-Regular","serif"">I indeed did see a DIE that had a DW_AT_specification and pointed to another die that also had a DW_AT_specification. Regardless of what the DWARF spec says, compilers or
post production DWARF tools are are producing DWARF that has these multiple chaining of specifications or abstract origins. There is also no enforcement of the DWARF spec anywhere, so compilers produce a wide variety of different DWARF that may or may not
be legal. We have "llvm-dwarfdump --verify" but it isn't exhaustive in what it reports. So I would vote that we have a DWARF parser that can handle what ever is thrown at it when possible. Just my 2 cents.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Menlo-Regular","serif""><br>
I'm not suggesting the DWARF parser should crash or be unhelpful on such inputs - but the convenience of following abstract origin/specification DIE references to print names seems OK if it's limited to the situations we know make sense until we see something
else?<br>
<br>
So if we could see/figure out what producer is generating such DWARF and look an some examples, decide if it's meaningful/useful to support name printing in that case, I'd be all for it. Without that, I'd rather err on the side of simplicity and not support
the recursive case (& then have to handle/defend against cycles, etc).<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal">We have many tools here at Facebook that use LLVM's DWARF parser to symbolicate information and rely on the getting the names correctly from any producer of DWARF.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
"correctly" is what I'm wondering about - without seeing the example DWARF it's hard to know if this is the correct answer or not.<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">
<div>
<div>
<p class="MsoNormal">I can't tell you exactly which compilers generate DWARF with multiple indirections, but I do know it happens. There are also many post production tools that we have here and take an existing linked binary and produce a new binary and fix
the DWARF up. So in these cases, it isn't the compiler itself that ends up vending the final DWARF. So even if we identify the compiler that might produce this DWARF, there is no guarantee that the DWARF won't get changed. Granted, none of these tools will
change abbreviation declarations that I know of. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That being said I would be fine not dealing with recursion as the case that I fixed didn't have recursion. And if the DWARF is invalid I don't know how much we can/should do to try and recover.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:4.8pt"><br>
Sorry, when I say "recursion" I mean "more than one specification or more than one abstract_origin in the chain" - which I think is what your patch that switched to recursion was implementing, right?<br>
<br>
I'd like to see an example of that, to know what it is, why it exists/what it means & so we can know why we're supporting it, before we do.<br>
<br>
Yeah, even if it's a chain of weird tools - if it's producing dwarf that's not really meaningful (perhaps the tools are buggy, etc) then it's probably best not to add support for it in Clang, for example.<br>
<br>
<span style="font-size:9.0pt;font-family:"Menlo-Regular","serif""><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>