DWARF2 info not being generated correctly for PPC targets?
Thomas de Lellis
tdel@windriver.com
Fri Jun 16 11:33:00 GMT 2000
Greetings list!
We've noticed something a bit odd with dwarf2 debugging info on the PPC
(only) which seems to be related to the use of RELA relocations...
Not sure I quite understand this, but apprently with RELA relocations
offsets are stored in relocation addends and not placed into the object
code itself (as with REL).
The dwarf debug info looks normal when you examine a single PPC .o file.
What happens though is when you partially link more than one PPC .o
file, dwarf offsets are still zero.
The following tries to show what's going on...
> cat 1.c
test1(){}
> cat 2.c
test2(){}
> ccppc -S -g 1.c
> cat 1.s
.file "1.c"
gcc2_compiled.:
.section .debug_abbrev
.Ldebug_abbrev0: <<<<< referencing this symbol
.section .text
.Ltext0:
.section .debug_info
[...snip...]
.byte 0xb
.byte 0,0
.section .debug_info
.4byte 0x74
.2byte 0x2
.4byte .Ldebug_abbrev0 <<<<< RELA relocation used on PPC
.byte 0x4 for this
.byte 0x1
.string "1.c"
[...snip...]
Now, when 1.o and 2.o are partially linked producing 3.o...
> ./x
arch=ppc
+ ccppc -c -g 1.c
+ ccppc -c -g 2.c
+ ldppc -r -o 3.o 1.o 2.o
+ readelfppc -wi 3.o
The section .debug_info contains:
Compilation Unit:
Length: 116
Version: 2
Abbrev Offset: 0 <<<<< first one ok...
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name : 1.c
DW_AT_comp_dir : /folk/tdel/dw/ppcVx6.0
DW_AT_producer : GNU C gcc-2.96 19990621 Tornado 3.0
DW_AT_language : 1 (ANSI C)
DW_AT_low_pc : 0
DW_AT_high_pc : 0x1c
DW_AT_stmt_list : 0
<1><58>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : test1
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <70>
DW_AT_low_pc : 0
DW_AT_high_pc : 0x1c
DW_AT_frame_base : 1 byte block: 6f (reg 31)
<1><70>: Abbrev Number: 3 (DW_TAG_base_type)
DW_AT_name : int
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
Compilation Unit:
Length: 116
Version: 2
Abbrev Offset: 0 <<<<< offset which should be non-zero always zero?!
Pointer Size: 4
<0><83>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name : 2.c
DW_AT_comp_dir : /folk/tdel/dw/ppcVx6.0
DW_AT_producer : GNU C gcc-2.96 19990621 Tornado 3.0
DW_AT_language : 1 (ANSI C)
DW_AT_low_pc : 0
DW_AT_high_pc : 0x1c
DW_AT_stmt_list : 0
<1><d0>: Abbrev Number: 2 (DW_TAG_subprogram)
[...snip...]
Here's the same example produced with pentium (other arches not using
RELA)
[tdel.test]michigan> ./x
arch=pentium
+ ccpentium -c -g 1.c
+ ccpentium -c -g 2.c
+ ldpentium -r -o 3.o 1.o 2.o
+ readelfpentium -wi 3.o
The section .debug_info contains:
Compilation Unit:
Length: 121
Version: 2
Abbrev Offset: 0 <<<<< so far so good
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name : 1.c
DW_AT_comp_dir : /folk/tdel/dw/ipentiumVx6.0
DW_AT_producer : GNU C gcc-2.96 19990621 Tornado 3.0
DW_AT_language : 1 (ANSI C)
DW_AT_low_pc : 0
DW_AT_high_pc : 0x7
DW_AT_stmt_list : 0
<1><5d>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : test1
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <75>
DW_AT_low_pc : 0
DW_AT_high_pc : 0x7
DW_AT_frame_base : 1 byte block: 55 (reg 5)
<1><75>: Abbrev Number: 3 (DW_TAG_base_type)
DW_AT_name : int
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
Compilation Unit:
Length: 121
Version: 2
Abbrev Offset: 51 <<<<<<<<<<< AHA! non-zero offset
Pointer Size: 4
<0><88>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_name : 2.c
DW_AT_comp_dir : /folk/tdel/dw/ipentiumVx6.0
DW_AT_producer : GNU C gcc-2.96 19990621 Tornado 3.0
DW_AT_language : 1 (ANSI C)
DW_AT_low_pc : 0x10
DW_AT_high_pc : 0x17
DW_AT_stmt_list : 43
<1><da>: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : test2
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type : <75>
DW_AT_low_pc : 0x10
DW_AT_high_pc : 0x17
DW_AT_frame_base : 1 byte block: 55 (reg 5)
<1><f2>: Abbrev Number: 3 (DW_TAG_base_type)
DW_AT_name : int
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
Seems to me that we need to be storing offsets at least for sections
tagged DEBUGGING even with RELA relocations. Is that safe though to do?
regards!
tom
More information about the Binutils
mailing list