Load address issue

[Schweikhardt Jens (LP21)]

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