This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Partial linking problems on ELF32 PPC
- From: Ranjit Deshpande <RanjitDeshpande at AirgoNetworks dot com>
- To: <binutils at sources dot redhat dot com>
- Date: Sat, 28 Dec 2002 01:42:58 -0800
- Subject: 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> ------------------------------