[LLVMdev] More DWARF problems

[Devang Patel]

On Mar 31, 2011, at 12:57 AM, Talin wrote:

> On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote:
> 
> On Mar 29, 2011, at 7:29 PM, Talin wrote:
> 
>> 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:
>> 
>> gdb stack crawl at point of internal error:
>> [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300]
>> [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die_in_comp_unit+0x65) [0xc0e19]
>> [ 2 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die+0x2d4) [0xcf07f]
>> [ 3 ] /usr/libexec/gdb/gdb-i386-apple-darwin (fixup_partial_die+0x29) [0xcf0b3]
>> [ 4 ] /usr/libexec/gdb/gdb-i386-apple-darwin (scan_partial_symbols+0x26) [0xcf9e7]
>> [ 5 ] /usr/libexec/gdb/gdb-i386-apple-darwin (dwarf2_build_psymtabs+0xc54) [0xd093c]
>> [ 6 ] /usr/libexec/gdb/gdb-i386-apple-darwin (macho_symfile_read+0x145) [0x163b15]
>> [ 7 ] /usr/libexec/gdb/gdb-i386-apple-darwin (syms_from_objfile+0x62d) [0x52259]
>> [ 8 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_with_addrs_or_offsets_using_objfile+0x338) [0x561e7]
>> [ 9 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_with_addrs_or_offsets_using_objfile+0x2da) [0x56189]
>> [ 10 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_name_with_addrs_or_offsets+0x7a) [0x563c9]
>> [ 11 ] /usr/libexec/gdb/gdb-i386-apple-darwin (symbol_file_add_main_1+0xf2) [0x56e36]
>> [ 12 ] /usr/libexec/gdb/gdb-i386-apple-darwin (catch_command_errors+0x4d) [0x7ac88]
>> /SourceCache/gdb/gdb-966/src/gdb/dwarf2read.c:7593: internal-error: could not find partial DIE in cache
>> 
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.
>> Quit this debugging session? (y or n) 
>> 
>> 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.
> 
> 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.
> 
> 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?


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.
--- c++ --- 
class A {
public:	int foo();
};
int A::foo() { return 42; }
A a;
----
-
Devang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110331/f4994b75/attachment.html>