I hate to be a nag, but after several days of working on this I am still utterly stumped.<div><br></div><div>Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause.</div>
<div><br></div><div>Based on the advice in the earlier thread, I've been using dwarfdump to try and isolate the problem. This was helpful in solving the earlier problem, but isn't helping me with the current problem.</div>
<div><br></div><div>When I run dwarfdump -a, it prints a couple hundred pages of debug info, and then segfaults. The last few lines before the segfault look like this:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div><div><font class="Apple-style-span" face="'courier new', monospace">.debug_inlined contents:</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace">< EMPTY ></font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">.debug_frame contents:</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"><br></font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">0x00000000: CIE</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> length: 0x00000010</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> CIE_id: 0xffffffff</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> version: 0x01</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> augmentation: ""</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> code_align: 1</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> data_align: -4</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> ra_register: 0x08</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> DW_CFA_def_cfa (esp, 4)</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> DW_CFA_offset (eip, 0)</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> DW_CFA_nop</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> DW_CFA_nop</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> Instructions: Init State: CFA=esp+4 eip=[esp+4]</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"><br>
</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"><br></font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace">0x00000014: FDE</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace"> length: 0x00000028</font></div></div><div><div><font class="Apple-style-span" face="'courier new', monospace"> CIE_pointer: 0x00000000</font></div>
</div><div><div><font class="Apple-style-span" face="'courier new', monospace">Segmentation fault</font></div></div></blockquote><div><div><br></div><div>If I grep through the output of dwarfdump, there are no other CIE or FDE definitions that occur before this point, so I assume that the problem isn't just this particular FDE.</div>
<div><br></div><div>One difficulty here is that I don't know which calls to DIFactory produce these data structures. Usually my solution of last resort when dealing with intractable debugging problems like this is to start commenting out code until the problem goes away, but in this case I don't know where to even start. If I comment out *all* the DWARF-generating code, then obviously the problem goes away. :)</div>
<div><br></div><div>I did in fact discover that if I comment out all calls to DIFactory::CreateSubprogram, the problem disappears - but then I don't have any debugging info. (Well, I still have all the DINodes for my data structures, just not functions.) I've also commented out all of the declarations of parameters and local variables, which doesn't prevent the problem from occurring. (Since my current understanding is that CIE and FDE are used to describe the call frame, I'm trying to simplify the problem as much as possible.)</div>
<div><br></div><div>I've carefully studied the source code of CGDebugInfo in clang as a working example. One puzzlement is that there's a discrepancy between what the "source level debugging with LLVM" docs say and what clang does: According to the docs, DW_TAG_formal_parameter is used to specify a formal parameter in a function type descriptor, but according to a code search, the name "DW_TAG_formal_parameter" does not appear anywhere in the clang source code. Instead, the argument array that is used when creating a function type descriptor contains only the bare types, not types wrapped in a formal parameter DIE.</div>
<div><br></div><div>However, since I've tried it both ways (wrapped and unwrapped) and the dwarfdump crash occurs either way, this latter issue is of lesser concern.</div><div><br></div><div>At the moment I'm experimenting with the parameters to CreateSubprogram, trying every possible permutation of inputs that I can think of in hope of stumbling on the right answer. I can't think of what else to do.</div>
<div><br></div><div>Note that I am calling assert(diNode.Verify()) on every DINode after it's created, so I know that it's valid up to that point at least. However, the checks in Verify() aren't very extensive. (Also, I've observed in the past that it's kind of inconvenient that Verify() only returns a boolean result when it fails, with no indication of what you did wrong.)</div>
<div><br></div><div>All of this is with the current LLVM head, although I was getting the same problems with the version from about 2 months ago.</div><div><br></div><div><div class="gmail_quote">On Thu, Sep 2, 2010 at 11:43 PM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com">viridia@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">OK here's another question along these lines: According to the LLVM source level debugging manual:<div><br></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>
<div class="gmail_quote">The first member of subroutine (tag = DW_TAG_subroutine_type) type elements is the return type for the subroutine. The remaining elements are the formal arguments to the subroutine.</div></div></blockquote>
<div><div class="gmail_quote"><br></div><div class="gmail_quote">Now, when I read "formal arguments" I'm assuming we're talking about DIEs of type DW_TAG_formal_parameter. However, when I look in the code in CGDebugInfo.cpp in clang, I see that the arguments are in fact the bare types, not the formal parameter declarations.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Here's what my code looks like:</div><div class="gmail_quote"><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> const ParameterList & params = type->params();</font></div></div></div><div><div class="gmail_quote">
<div class="gmail_quote"><font face="'courier new', monospace"> for (ParameterList::const_iterator it = params.begin(); it != params.end(); ++it) {</font></div></div></div><div><div class="gmail_quote">
<div class="gmail_quote"><font face="'courier new', monospace"> const ParameterDefn * param = *it;</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> DIType ptype = genDIParameterType(param->type());</font></div>
</div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> ptype = dbgFactory_.CreateDerivedTypeEx(</font></div></div></div><div><div class="gmail_quote">
<div class="gmail_quote"><font face="'courier new', monospace"> dwarf::DW_TAG_formal_parameter,</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> dbgCompileUnit_,</font></div>
</div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> param->name() != NULL ? param->name() : "",</font></div></div>
</div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> genDIFile(param),</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote">
<font face="'courier new', monospace"> getSourceLineNumber(param->location()),</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> getSizeOfInBits(param->internalType()->irParameterType()),</font></div>
</div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> getInt64Val(0),</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote">
<font face="'courier new', monospace"> getInt64Val(0), 0,</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> ptype);</font></div>
</div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> DASSERT(ptype.Verify());</font></div></div></div><div><div class="gmail_quote">
<div class="gmail_quote"><font face="'courier new', monospace"> args.push_back(ptype);</font></div></div></div><div><div class="gmail_quote"><div class="gmail_quote"><font face="'courier new', monospace"> }</font></div>
</div></div></blockquote><div><div class="gmail_quote"><div><br></div><div>However, if I go by what's in clang, it seems that the DW_TAG_formal_parameter is unnecessary. Is this correct?</div><div><br></div><div>And I'd still like to see some of these questions addressed in the actual HTML documentation, as opposed to just responding here on the mailing list. :)</div>
<div><br></div></div><div><div></div><div class="h5"><div class="gmail_quote">On Tue, Aug 31, 2010 at 10:32 AM, Devang Patel <span dir="ltr"><<a href="mailto:dpatel@apple.com" target="_blank">dpatel@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On Aug 31, 2010, at 9:03 AM, Talin wrote:<br>
<br>
</div><div>> 4) What is the meaning of the "inlinedAt" argument for DebugLoc::get()? Does it mean the location where the inlined code was defined, or the location where it was expanded?<br>
<br>
the location where it was expanded<br>
</div>-<br>
<font color="#888888">Devang</font></blockquote></div><br><br clear="all"><br></div></div>-- <br>-- Talin<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>
</div></div>