[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
2.15 binutils ld --emit-relocs generates corrupt ELF
|
From: |
Kyle McKay |
|
Subject: |
2.15 binutils ld --emit-relocs generates corrupt ELF |
|
Date: |
Mon, 9 Aug 2004 17:18:29 -0700 |
The binutils-2.15 package was built and installed using the following
arguments to configure:
--target=arm-elf --prefix=/armsw --with-local-prefix=/armsw/local
--with-sysroot=/armsw --disable-shared --disable-threads
--with-cpu=arm7tdmi --with-dwarf2 --disable-nls --with-newlib
--program-prefix=arm-elf-
After adding /armsw/bin to the PATH, arm-elf-ld --version reports:
GNU ld version 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Now, the following sample code:
#include <stdio.h>
const char *infoString =
"Foo Info\n"
"$Header$\n"
__DATE__ " " __TIME__ "\n";
static char space[1000];
int main()
{
printf("%s", infoString);
return 0;
}
was compiled using the arm-elf tools as follows (obviously GCC and
newlib were built and installed as well, but they are not relevant to
this bug. GCC-3.4.1 and newlib-1.12.0 were used with the identical
configure options as already listed above for binutils):
arm-elf-gcc -Xlinker --emit-relocs -o sample.15.elf sample.c
The resulting sample.15.elf was examined using the arm-elf-readelf
utility as follows:
arm-elf-readelf -S sample.15.elf
Here is the output:
There are 28 section headers, starting at offset 0x11750:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .init PROGBITS 00008000 008000 00001c 00 AX
0 0 4
[ 2] .rel.init REL 00000000 010964 000010 08
26 1 4
[ 3] .text PROGBITS 0000801c 00801c 007d1c 00 AX
0 0 4
[ 4] .rel.text REL 00000000 010964 002e88 08
26 3 4
[ 5] .fini PROGBITS 0000fd38 00fd38 000018 00 AX
0 0 4
[ 6] .rel.fini REL 00000000 010964 000008 08
26 5 4
[ 7] .rodata PROGBITS 0000fd50 00fd50 00023c 00 A
0 0 4
[ 8] .rel.rodata REL 00000000 010964 000050 08
26 7 4
[ 9] .data PROGBITS 0001008c 01008c 0008c0 00 WA
0 0 4
[10] .rel.data REL 00000000 010964 000840 08
26 9 4
[11] .eh_frame PROGBITS 0001094c 01094c 000004 00 A
0 0 4
[12] .ctors PROGBITS 00010950 010950 000008 00 WA
0 0 4
[13] .dtors PROGBITS 00010958 010958 000008 00 WA
0 0 4
[14] .jcr PROGBITS 00010960 010960 000004 00 WA
0 0 4
[15] .bss NOBITS 00010964 010964 000504 00 WA
0 0 4
[16] .comment PROGBITS 00000000 010964 000318 00
0 0 1
[17] .debug_aranges PROGBITS 00000000 010c80 0000c0 00
0 0 8
[18] .rel.debug_arange REL 00000000 010d40 000060 08
26 11 4
[19] .debug_info PROGBITS 00000000 010d40 000338 00
0 0 1
[20] .rel.debug_info REL 00000000 011078 0000c0 08
26 13 4
[21] .debug_abbrev PROGBITS 00000000 011078 000078 00
0 0 1
[22] .debug_line PROGBITS 00000000 0110f0 00059b 00
0 0 1
[23] .rel.debug_line REL 00000000 01168c 000030 08
26 16 4
[24] .stack PROGBITS 00080000 01168c 000000 00 W
0 0 1
[25] .shstrtab STRTAB 00000000 01168c 0000c2 00
0 0 1
[26] .symtab SYMTAB 00000000 011bb0 001db0 10
27 13f 4
[27] .strtab STRTAB 00000000 013960 000a02 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
Please notice the values in the "Off" column for sections 2,4,6,8,10,15
& 16. They are all the same value. It turns out the ELF file is
corrupt. After examination of the ELF file, it appears that all the
overlapping sections were indeed written to the ELF file, but all
starting at the same file offset, so they overwrite the previous
contents. The ELF file is not usable.
Under regression testing, binutils-2.14 was then built and installed
(with the same configure options as above). arm-elf-ld then reports
this version:
GNU ld version 2.14 20030612
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
The same file was compiled using the following:
arm-elf-gcc -Xlinker --emit-relocs -o sample.14.elf sample.c
The sample.14.elf was then examined with:
arm-elf-readelf -S sample.14.elf
producing this output:
There are 29 section headers, starting at offset 0x11754:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .init PROGBITS 00008000 008000 00001c 00 AX
0 0 4
[ 2] .rel.init REL 00000000 011bdc 000010 08
27 1 4
[ 3] .text PROGBITS 0000801c 00801c 007d1c 00 AX
0 0 4
[ 4] .rel.text REL 00000000 011bec 002e88 08
27 3 4
[ 5] .fini PROGBITS 0000fd38 00fd38 000018 00 AX
0 0 4
[ 6] .rel.fini REL 00000000 014a74 000008 08
27 5 4
[ 7] .rodata PROGBITS 0000fd50 00fd50 000240 00 A
0 0 4
[ 8] .rel.rodata REL 00000000 014a7c 000050 08
27 7 4
[ 9] .data PROGBITS 00010090 010090 0008c0 00 WA
0 0 4
[10] .rel.data REL 00000000 014acc 000840 08
27 9 4
[11] .eh_frame PROGBITS 00010950 010950 000004 00 A
0 0 4
[12] .ctors PROGBITS 00010954 010954 000008 00 WA
0 0 4
[13] .dtors PROGBITS 0001095c 01095c 000008 00 WA
0 0 4
[14] .jcr PROGBITS 00010964 010964 000004 00 WA
0 0 4
[15] .sbss PROGBITS 00010968 010968 000000 00 W
0 0 1
[16] .bss NOBITS 00010968 010968 000504 00 WA
0 0 4
[17] .comment PROGBITS 00000000 010968 000318 00
0 0 1
[18] .debug_aranges PROGBITS 00000000 010c80 0000c0 00
0 0 8
[19] .rel.debug_arange REL 00000000 01530c 000060 08
27 12 4
[20] .debug_info PROGBITS 00000000 010d40 000338 00
0 0 1
[21] .rel.debug_info REL 00000000 01536c 0000c0 08
27 14 4
[22] .debug_abbrev PROGBITS 00000000 011078 000078 00
0 0 1
[23] .debug_line PROGBITS 00000000 0110f0 00059b 00
0 0 1
[24] .rel.debug_line REL 00000000 01542c 000030 08
27 17 4
[25] .stack PROGBITS 00080000 01168b 000000 00 W
0 0 1
[26] .shstrtab STRTAB 00000000 01168b 0000c8 00
0 0 1
[27] .symtab SYMTAB 00000000 01545c 001d90 10
28 13d 4
[28] .strtab STRTAB 00000000 0171ec 000a02 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
Notice how binutils-2.14 does not have the problem. The ".rel"
sections no longer overlap themselves nor any other section.
This problem only occurs when the "--emit-relocs" directive is present
(which is required for my application).
Rough guess would be that the "--emit-relocs" code is failing to
advance the "position-in-file-to-start-writing-next-section" pointer
after writing one of the ".rel" sections. In any case, someone
familiar with the "--emit-relocs" implementation in ld can probably fix
this issue rather quickly seeing as how the 2.14 version works
properly.
It is possible to reduce this example to one that only uses
"arm-elf-ld" and object files, but that is not as simple to report.
Any further questions, please contact me.
Thanks,
Kyle McKay
address@hidden
- 2.15 binutils ld --emit-relocs generates corrupt ELF,
Kyle McKay <=