[LLVMdev] More DWARF problems

[Talin]

>
> This means the subprogram type is invalid. Set a breakpoint inside
> createSubprogramDIE() where addType() is used to add AT_type.
>

OK that was useful. I figured out what at least one of my problems was - an
incorrect encoding of type "void".

However, I'm still see errors in dwarfdump output, although fewer than
before. Here's a sample of one of the errors I am getting:

0x000192a4: DIE attribute 0x000192a5:  AT_type/FORM_ref4 has a value
0x000194c7 that is not in the current compile unit in the .debug_info
section.


And here's the relevant DIE that it's referring to:

0x0001929b:     TAG_array_type [12] *
0x0001929c:      AT_sibling( cu + 0x00000177 => {0x000192ab} )
0x000192a0:      AT_type( cu + 0x000000b2 => {0x000191e6} ( uint32 ) )

0x000192a4:         TAG_subrange_type [13]
*0x000192a5:          AT_type( cu + 0x00000393 => {0x000194c7} (  ) )*
0x000192a9:          AT_upper_bound( 0x01 )

0x000192aa:         NULL


dwarfdump is complaining because the AT_type attribute of the subrange is
pointing to an invalid offset. Now, I created this subrange with the call:

       diBuilder_.getOrCreateSubrange(0, 1);

As you can see there's nothing there for me to screw up. So I'm puzzled as
to where that AT_type is coming from.

Another strange thing: When I run dwarfdump on the .o file, I get far fewer
error messages than when I run it on the final executable that was built
from just that one .o file. For example, these errors (and many more) only
shows up on the executable:

0x00000889: DIE attribute 0x0000088a:  AT_type/FORM_ref4 has a value
0x00001053 that is not in the current compile unit in the .debug_info
section.
0x000008b4: DIE attribute 0x000008b5:  AT_type/FORM_ref4 has a value
0x000010a1 that is not in the current compile unit in the .debug_info
section.
0x000008d6: DIE attribute 0x000008d7:  AT_type/FORM_ref4 has a value
0x00001053 that is not in the current compile unit in the .debug_info
section.


Looking at the first of these, here's what the DIE from the executable looks
like:

0x0000087d:     TAG_class_type [9] *
0x0000087e:      AT_sibling( cu + 0x000000ad => {0x000008a0} )
0x00000882:      AT_name( .debug_str[0x000001ff] = "tart.reflect.Type" )
0x00000886:      AT_byte_size( 0x0c )
0x00000887:      AT_decl_file( 0x42 (
"/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Type.tart" ) )
0x00000888:      AT_decl_line( 0x05 ( 5 ) )

0x00000889:         TAG_inheritance [10]
*0x0000088a:          AT_type( cu + 0x00000860 => {0x00001053} (  ) )*
0x0000088e:          AT_data_member_location( <0x2> 23 00  ( plus-uconst
0x0000 ) )

0x00000891:         TAG_member [11]
0x00000892:          AT_name( .debug_str[0x00000211] = "_typeKind" )
0x00000896:          AT_type( cu + 0x00000063 => {0x00000856} ( NULL ) )
0x0000089a:          AT_decl_file( 0x3a (
"/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Module.tart" ) )
0x0000089b:          AT_decl_line( 0x17 ( 23 ) )
0x0000089c:          AT_data_member_location( <0x2> 23 08  ( plus-uconst
0x0008 ) )

0x0000089f:         NULL


Now, if I find the corresponding DIE from the .o file, here's what it looks
like:

0x000002c4:     TAG_class_type [9] *
0x000002c5:      AT_sibling( cu + 0x000002fb => {0x000002fb} )
0x000002c9:      AT_name( "tart.reflect.Type" )
0x000002db:      AT_byte_size( 0x0c )
0x000002dc:      AT_decl_file( 0x42 (
"/Users/talin/Projects/tart/trunk/lib/gc1/tart/gc1/Type.tart" ) )
0x000002dd:      AT_decl_line( 0x05 ( 5 ) )

0x000002de:         TAG_inheritance [10]
*0x000002df:          AT_type( cu + 0x00000a7b => {0x00000a7b} (
tart.core.Object ) )*
0x000002e3:          AT_data_member_location( <0x2> 23 00  ( plus-uconst
0x0000 ) )

0x000002e6:         TAG_member [11]
0x000002e7:          AT_name( "_typeKind" )
0x000002f1:          AT_type( cu + 0x00000221 => {0x00000221} ( TypeKind ) )
0x000002f5:          AT_decl_file( 0x4b (
"/Users/talin/Projects/tart/trunk/lib/gc1/tart/gc1/GC1.tart" ) )
0x000002f6:          AT_decl_line( 0x17 ( 23 ) )
0x000002f7:          AT_data_member_location( <0x2> 23 08  ( plus-uconst
0x0008 ) )

0x000002fa:         NULL


As you can see, the AT_type from the TAG_inheritance DIE is pointing to a
valid DIE in the .o file, but not in the executable. Here's the type it's
pointing to:

0x00000a7b:     TAG_class_type [9] *
0x00000a7c:      AT_sibling( cu + 0x00000ab9 => {0x00000ab9} )
0x00000a80:      AT_name( "tart.core.Object" )
0x00000a91:      AT_byte_size( 0x08 )
0x00000a92:      AT_decl_file( 0x12 (
"/Users/talin/Projects/tart/trunk/lib/gc1/tart/gc1/Object.tart" ) )
0x00000a93:      AT_decl_line( 0x07 ( 7 ) )

0x00000a94:         TAG_member [11]
0x00000a95:          AT_name( "__tib" )
0x00000a9b:          AT_type( cu + 0x00000a75 => {0x00000a75} (
tart.core.TypeInfoBlock* ) )
0x00000a9f:          AT_decl_file( 0x4b (
"/Users/talin/Projects/tart/trunk/lib/gc1/tart/gc1/GC1.tart" ) )
0x00000aa0:          AT_decl_line( 0x08 ( 8 ) )
0x00000aa1:          AT_data_member_location( <0x2> 23 00  ( plus-uconst
0x0000 ) )

0x00000aa4:         TAG_member [11]
0x00000aa5:          AT_name( "__gcstate" )
0x00000aaf:          AT_type( cu + 0x00000094 => {0x00000094} ( int32 ) )
0x00000ab3:          AT_decl_file( 0x4b (
"/Users/talin/Projects/tart/trunk/lib/gc1/tart/gc1/GC1.tart" ) )
0x00000ab4:          AT_decl_line( 0x09 ( 9 ) )
0x00000ab5:          AT_data_member_location( <0x2> 23 04  ( plus-uconst
0x0004 ) )

0x00000ab8:         NULL


Now, the .o file is being produced by llc, and the executable is being
produced by:

/usr/bin/c++ -g -o $PRGNAME $PRGNAME.o runtime/libruntime.a


So the question is - why are the DIEs which are correct in the .o file being
garbled when they are in the executable?

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