m68k-elf: Zeroed area in ELF file

[Christian Meusel]

Hello!

I'm compiling eCos for the ColdFire MCF5282. When linking all together, 
the resulting ELF file contains a corrupted interrupt vector table. 
Excactly the first kilobyte of the ROM interrupt vector table is zeroed 
- no matter what the code from object or archive files contains.

Linking occurs with help of the attached linker script and linking is 
invoked as follows:

     m68k-elf-gcc -m528x -g -nostdlib -Wl,--gc-sections \
         -Wl,-static -L<BUILDPATH>/install/lib -Ttarget.ld \
         -o <BUILDPATH>/install/bin/redboot.elf \
         <BUILDPATH>/install/lib/version.o

The data for the vector table is provided in an archive named 
libtarget.a which is referenced by the linker script. In this archive, 
the vector table contains references to relocatable symbols.

When compiling and linking with GCC 3.4.6 I'm getting the expected 
result with correctly resolved symbols in the interrupt vector table. 
The situation changes when I'm using one of the following GCC 4 variants:

     GCC 4.0.4
     GCC 4.1.2
     GCC 4.2.4

All ELF files generated by using these versions for linking have the 
first kilobyte of the interrupt vector table zeroed. The interrupt 
vector table resides in the section ".romvec" at the lowest ROM address.


Any ideas? How to make GCC 4 not to zero the first kilobyte of ROM?


Best regards

Christian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: target.ld
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20080722/8adb0dab/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3367 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20080722/8adb0dab/attachment.bin>