DWARF2 info not being generated correctly for PPC targets?

DWARF2 info not being generated correctly for PPC targets?

[Thomas de Lellis]

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

Re: DWARF2 info not being generated correctly for PPC targets?

[Geoff Keating]

> Date: Fri, 16 Jun 2000 11:33:28 -0700
> From: Thomas de Lellis <tdel@windriver.com>
> CC: igor@mail.wrs.com
> 
> 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).

Yes.  This saves us from the problems that you have on MIPS where
there isn't room to store the addends.

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

Yes, this is because .o files are intermediate files.  When you link
them into a final executable the relocations will be resolved and you
will get the correct values.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: DWARF2 info not being generated correctly for PPC targets?

[Geoff Keating]

> > Date: Fri, 16 Jun 2000 11:33:28 -0700
> > From: Thomas de Lellis <tdel@windriver.com>
> > CC: igor@mail.wrs.com

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

> Yes, this is because .o files are intermediate files.  When you link
> them into a final executable the relocations will be resolved and you
> will get the correct values.

Oh, wind river!

Sorry, I didn't see.

In that case, you need a debugger that can resolve relocations.
-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: DWARF2 info not being generated correctly for PPC targets?

[Thomas de Lellis]

Greetings Geoff!

thanks for the reply.  I am looking for ways to accommodate a 3rd party
who are trying to make their debugger compatible with GNU-ld-produced .o
files but expects these dwarf offset fields to contain valid values even
in relocatable .o files.

Is it too risky or are there side effects in simply dropping the RELA
addend offset into the dwarf debugging info as well as keep the offset
in the addend?

regards!

tom


Geoff Keating wrote:
> > What happens though is when you partially link more than one PPC .o
> > file, dwarf offsets are still zero.
> 
> Yes, this is because .o files are intermediate files.  When you link
> them into a final executable the relocations will be resolved and you
> will get the correct values.
> 
> --
> - Geoffrey Keating <geoffk@cygnus.com>

Re: DWARF2 info not being generated correctly for PPC targets?

[Geoff Keating]

> Date: Fri, 16 Jun 2000 15:54:18 -0700
> From: Thomas de Lellis <tdel@windriver.com>
> CC: binutils@sourceware.cygnus.com, igor@mail.wrs.com
> 
> Greetings Geoff!
> 
> thanks for the reply.  I am looking for ways to accommodate a 3rd party
> who are trying to make their debugger compatible with GNU-ld-produced .o
> files but expects these dwarf offset fields to contain valid values even
> in relocatable .o files.
> 
> Is it too risky or are there side effects in simply dropping the RELA
> addend offset into the dwarf debugging info as well as keep the offset
> in the addend?

This is safe (those places in the .o file are ignored in the final
link), but it may not give what the debugger expects.

For example, if the debugging info contained

    .4byte foo

and 'foo' is an external symbol, the relocation will have an addend of
0.  I don't know enough about DWARF to know if this can happen.

-- 
- Geoffrey Keating <geoffk@cygnus.com>