<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 31, 2011, at 12:57 AM, Talin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <span dir="ltr"><<a href="mailto:dpatel@apple.com">dpatel@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Mar 29, 2011, at 7:29 PM, Talin wrote:</div><br><blockquote type="cite">I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X:<div>
<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="'courier new', monospace">gdb stack crawl at point of internal error:</font></div>
</div><div><div><font face="'courier new', monospace">[ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300]</font></div></div><div><div><font face="'courier new', monospace">[ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die_in_comp_unit+0x65) [0xc0e19]</font></div>
</div><div><div><font face="'courier new', monospace">[ 2 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die+0x2d4) [0xcf07f]</font></div></div><div><div><font face="'courier new', monospace">[ 3 ] /usr/libexec/gdb/gdb-i386-apple-darwin (fixup_partial_die+0x29) [0xcf0b3]</font></div>
</div><div><div><font face="'courier new', monospace">[ 4 ] /usr/libexec/gdb/gdb-i386-apple-darwin (scan_partial_symbols+0x26) [0xcf9e7]</font></div></div><div><div><font face="'courier new', monospace">[ 5 ] /usr/libexec/gdb/gdb-i386-apple-darwin (dwarf2_build_psymtabs+0xc54) [0xd093c]</font></div>
</div><div><div><font face="'courier new', monospace">[ 6 ] /usr/libexec/gdb/gdb-i386-apple-darwin (macho_symfile_read+0x145) [0x163b15]</font></div></div><div><div><font face="'courier new', monospace">[ 7 ] /usr/libexec/gdb/gdb-i386-apple-darwin (syms_from_objfile+0x62d) [0x52259]</font></div>
</div><div><div><font face="'courier new', monospace">[ 8 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_with_addrs_or_offsets_using_objfile+0x338) [0x561e7]</font></div></div>
<div>
<div><font face="'courier new', monospace">[ 9 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_with_addrs_or_offsets_using_objfile+0x2da) [0x56189]</font></div></div><div><div><font face="'courier new', monospace">[ 10 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_name_with_addrs_or_offsets+0x7a) [0x563c9]</font></div>
</div><div><div><font face="'courier new', monospace">[ 11 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_main_1+0xf2) [0x56e36]</font></div></div><div><div><font face="'courier new', monospace">[ 12 ] /usr/libexec/gdb/gdb-i386-apple-darwin (catch_command_errors+0x4d) [0x7ac88]</font></div>
</div><div><div><font face="'courier new', monospace">/SourceCache/gdb/gdb-966/src/gdb/dwarf2read.c:7593: internal-error: could not find partial DIE in cache</font></div></div><div><div><font face="'courier new', monospace"><br>
</font></div></div><div><div><font face="'courier new', monospace">A problem internal to GDB has been detected,</font></div></div><div><div><font face="'courier new', monospace">further debugging may prove unreliable.</font></div>
</div><div><div><font face="'courier new', monospace">Quit this debugging session? (y or n) </font></div></div></blockquote><div><div><br></div><div>Now, all of this was working earlier, and I don't know whether it was something I did or a change in LLVM, but that's not important. The real question is how to track down the problem.</div>
</div></blockquote><div><br></div></div><div>I have seen gdb crash with this back trace when it has seen a subprogram specification DIE at top level, but the actual subprogram definition is not found. The definition DIE may not be found because either it is hiding deep in nested subclass or it may be missing all together in compiler output. One easy way to rule out this is to check all specification DIE's indentation level in dwarfdump output and check corresponding level of definition die referred by it.</div>
</div></div></blockquote><div><br></div><div>OK, given that much information I was able to track it down, which is that I was passing my struct type as the context parameter to DIBuilder.createMethod. If I change it to compile unit, this problem goes away. I had thought I had read somewhere that it was legal to use the enclosing class definition as the subroutine context, but now I can't find where I read it. In any case, I guess this means that I don't know the proper way to declare member functions in DWARF - that is, how can I declare method A of class B so that I can say "B.A" in the debugger and gdb knows where to find it?</div></div></blockquote><br></div><div><br></div><div>You put subroutine declaration inside the struct and put definition at compile unit level. Take a look at dwarfdump output for following simple c++ program.</div><div>--- c++ --- </div><div><div><font class="Apple-style-span" face="Courier">class A {</font></div><div><font class="Apple-style-span" face="Courier">public:</font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier"> </font></span><font class="Apple-style-span" face="Courier">int foo();</font></div><div><font class="Apple-style-span" face="Courier">};</font></div><div><font class="Apple-style-span" face="Courier">int A::foo() { return 42; }</font></div><div><font class="Apple-style-span" face="Courier">A a;</font></div><div>----</div><div>-</div><div>Devang</div><div><br></div></div></body></html>