This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Load address issue
- From: "Schweikhardt Jens (LP21)" <Jens dot Schweikhardt at tesat dot de>
- To: "'binutils at sourceware dot org'" <binutils at sourceware dot org>
- Date: Mon, 5 Aug 2013 15:11:43 +0200
- Subject: Load address issue
hello, world\n
I am trying to port an old embedded application from an ancient
toolchain to a current toolchain. To be precise, the ancient
toolchain is the powerpc cross toolchain as found in vxWorks 5.4
for Sparc/Solaris, which has this linker
solaris$ ldppc --version
ld version cygnus-2.6 (with BFD cygnus-2.6)
and the new toolchain running under Linux x86_64 is
linux64$ powerpc-ld --version
GNU ld (GNU Binutils) 2.23.2
I can compile, assemble and link a working application with the
new toolchain--except for the link step, which only produces a
working executable if I use the old linker. The link command is
ldppc -X -N -e _romInit -Ttext 00400000 \
-o vxWorks_compress romInit.o bootInit_kl.o version.o \
/opt/wind_patched/target/config/esp750/bsplib.a \
/opt/wind_patched/target/lib/libPPC604gnuvx.a vxWorks.Z.o
I have tracked this down to the "-Ttext 00400000" option. When this
option is present, the executable has an ELF header with a large zero
filled area to offset 64k (octal 0200000):
$ od -c vxWorks_compress|head
0000000 177 E L F 001 002 001 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000020 \0 002 \0 024 \0 \0 \0 001 \0 @ \0 \0 \0 \0 \0 4
0000040 \0 013 376 4 \0 \0 \0 \0 \0 4 \0 \0 001 \0 (
0000060 \0 017 \0 \f \0 \0 \0 001 \0 001 \0 \0 \0 @ \0 \0
0000100 \0 @ \0 \0 \0 \n 300 350 \0 \f \ 240 \0 \0 \0 007
0000120 \0 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0200000 \0 \0 \0 \0 \0 \f \0 \0 B M I d 023 \b 005
0200020 007 \0 \0 002 \0 @ \0 \0 \0 @ 9 364 \0 @ 9 364
Without "-Ttext 00400000" the zero filled area is gone, i.e.
$ ldppc -X -N -e _romInit \
-o vxWorks_compress.1 romInit.o bootInit_kl.o version.o \
/opt/wind_patched/target/config/esp750/bsplib.a \
/opt/wind_patched/target/lib/libPPC604gnuvx.a vxWorks.Z.o
$ od -c vxWorks_compress.1|head
0000000 177 E L F 001 002 001 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000020 \0 002 \0 024 \0 \0 \0 001 \0 004 \0 t \0 \0 \0 4
0000040 \0 \n 376 250 \0 \0 \0 \0 \0 4 \0 \0 001 \0 (
0000060 \0 017 \0 \f \0 \0 \0 001 \0 \0 \0 \0 \0 004 \0 \0
0000100 \0 004 \0 \0 \0 \n 301 \ \0 \f ] 024 \0 \0 \0 007
0000120 \0 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \f \0 \0 B M I d
0000200 023 \b 005 007 \0 \0 002 \0 @ \0 \0 \0 004 : h
0000220 \0 004 : h \0 016 301 \ \0 004 001 t \0 \0 \0 \0
But such an application does not boot because the "BMId" ID tag is not
at the expected offset 64k+8. Now the *new* linker also creates an executable
without the 64k zero padding, regardless of the presence of a
"-Ttext=00400000" option.
When I run "readelf -a" for both executables, one difference apart from
symbol addresses is the LOAD Offset:
(with -Ttext 00400000)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x00400000 0x00400000 0xac0e8 0xc5ca0 RWE 0x10000
(without -Ttext 00400000 or with the new linker)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00040000 0x00040000 0xac15c 0xc5d14 RWE 0x10000
The question now is: How can I tell the new linker to create an executable
with a LOAD Offset of 64k?
Regards,
Jens
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz:Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Peter Schlote, Guenther Adam, Jochen Huppert