This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

DWARF2 info not being generated correctly for PPC targets?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]