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>