[LLVMdev] More DWARF problems

[Talin]

On Thu, Mar 31, 2011 at 9:15 AM, Devang Patel <dpatel at apple.com> wrote:

>
> 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;
> ----
>

Wow, I never would have guessed that. Is this a limitation of DWARF or of
the LLVM generator? I ask because it seems somewhat C++-centric - many
languages (mine included) don't have separate definitions and declarations
for functions.

I'd say that if this is required, then there should be a note in the
debugging doc about it - or better yet, a helper method in DIBuilder that
automatically creates both the definition and the declaration.

-
> Devang
>
>


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