This is the mail archive of the binutils@sources.redhat.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]
Other format: [Raw text]

Partial linking problems on ELF32 PPC


Hello,

I've run into this problem while using partial linking with multiple object
files where the DWARF2 .debug_info section incorrectly tells me that a
string is at offset X in the merged .debug_str section. I do think that the
correct offset is present in rela.debug_info but none of the tools (objdump,
readelf or gdb) use this information.

Included below is the output from readelf -wi ./foo.o. I've chopped off the
uninteresting bits. Notice the DW_AT_name attribute for DW_TAG_compile_unit.
It shows the correct file name for the first CU, but the latter CU's are
screwed up. I have 3 objects: main.o main1.o main2.o and the link command
is:

$ ld -r -o foo.o main.o main1.o main2.o

What I have noticed is that the .debug_info section contains offsets into
.debug_str that are no longer valid after the merge.

I claim complete ignorance of how all of this works and the fact that the
rela.debug_info shows the offset into .debug_str correctly makes me think
that the offset is not completely lost after merging the .debug_info and
debug_str sections from the 3 objects.

However readelf and objdump both do not take the rela.debug_info into
account.

And being lazy, I wonder if Daniel Jacobowitz is lurking on this list so
that I might ask him if he is aware of this and has dealt with this in the
gdb code. From my extremely limited understanding of the gdb code, I don't
think that he has but I could be wrong. GDB does not find source files.

Objdump by the way, fails to display source for main1.c and main2.c since it
cannot find the source files.

Okay now for the versions of tools being used:

Gcc-3.2.1
Binutils-2.13.1
Gdb-5.3

on a powerpc GNU Linux box.

I've also tried the December 27 2002 CVS snapshot of binutils with the same
results.

-Ranjit


-----------------------------------------------------------------------

The section .debug_info contains:

  Compilation Unit @ 0:
   Length:        80
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0
     DW_AT_high_pc     : 0x28 40
     DW_AT_low_pc      : 0 0
     DW_AT_name        : (indirect string, offset: 0x0): main.c
     DW_AT_comp_dir    : (indirect string, offset: 0x7):
/home/ranjitd/build/tes
t_rela  
     DW_AT_producer    : (indirect string, offset: 0x2a): GNU C 3.2.1
     DW_AT_language    : 1      (ANSI C)
---------------------------- <SNIP> ------------------------------
  Compilation Unit @ 54:
   Length:        80
   Version:       2
   Abbrev Offset: 69
   Pointer Size:  4
 <0><5f>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0
     DW_AT_high_pc     : 0x28 40
     DW_AT_low_pc      : 0 0
     DW_AT_name        : (indirect string, offset: 0x0): main.c
     DW_AT_comp_dir    : (indirect string, offset: 0x8):
home/ranjitd/build/test
_rela   
     DW_AT_producer    : (indirect string, offset: 0x26): ain
     DW_AT_language    : 1      (ANSI C)
---------------------------- <SNIP> ------------------------------
  Compilation Unit @ a8:
   Length:        80
   Version:       2
   Abbrev Offset: 138
   Pointer Size:  4
 <0><b3>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0
     DW_AT_high_pc     : 0x28 40
     DW_AT_low_pc      : 0 0
     DW_AT_name        : (indirect string, offset: 0x1e): t_rela
     DW_AT_comp_dir    : (indirect string, offset: 0x0): main.c
     DW_AT_producer    : (indirect string, offset: 0x26): ain
     DW_AT_language    : 1      (ANSI C)
---------------------------- <SNIP> ------------------------------


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