Hello! When linking the attached files using the command line ld -q -T bss.lds attention.o libbss.a -o attention.bso with ld 2.18 targeted for ELF (tested on Linux with version 2.18-1 from Debian, and on Windows by building binutils 2.18.50 on MinGW with target "i386-pc-elf"), the first 8 bytes of the section ".bs.server.name" are overwritten with zero. I.e., objdump -s -j .bs.server.name attention.o gives Contents of section .bs.server.name: 0000 41747465 6e74696f 6e536967 6e00 AttentionSign. whereas objdump -s -j .bs.server.name attention.bso gives Contents of section .bs.server.name: 400620 00000000 00000000 6e536967 6e00 ........nSign. A similar problem occurs with the file "car.o"; in that case the entire contents of ".bs.server.name" and ".bs.server.service" come out as zero. The section lengths are correct, however. Many similar files are linked just fine, but the problem is reproducable with these specific files, even though it looks pretty random to me. There are no relocs in the affected sections, so the section contents should stay exactly the same IMHO. Please mail me if you want to generate the files yourself. Thanks, Sebastian Reichelt
Created attachment 2156 [details] object file whose section contents are changed
Created attachment 2157 [details] object file whose section contents are changed
Created attachment 2158 [details] static library required to link attached files
Created attachment 2159 [details] ld script to link attached files
It works with binutils in CVS as of 2007-12-25: ./ld -m elf_i386 -o x -T bss.lds attention.o libbss.a objdump -s -j .bs.server.name attention.o attention.o: file format elf32-i386 Contents of section .bs.server.name: 0000 41747465 6e74696f 6e536967 6e00 AttentionSign. objdump -s -j .bs.server.name x x: file format elf32-i386 Contents of section .bs.server.name: 400620 41747465 6e74696f 6e536967 6e00 AttentionSign.
Created attachment 2160 [details] updated bss.lds I'm sorry; I somehow managed to upload an outdated bss.lds file. When using the attached file instead, I am able to reproduce the problem with the latest version from CVS. I apologize for the inconvenience.
Confirmed.
This regression was introduced by http://sourceware.org/ml/binutils-cvs/2007-05/msg00158.html
Thank you for the really quick response! I guess what I am trying to do here probably does not make much sense. The stabs debugging sections originate from a COFF-specific .s file generated by the MinGW version of GCC. I kept them in the object file just because that file is not the final output of the build process, and I wanted to keep the debug info for reference. I didn't realize that these sections were the ones causing the problems. In short, an error message would be perfectly sufficient for me.
The bug is trigger by the linker script: /* Server size info */ .data.server (NOLOAD) : { *(.data.server) } Linker marks the .data.server section as SHT_NOBITS, which is wrong since SHT_NOBITS section doesn't occupy space on disk.
There are /* An instruction to the linker to not output the section even if it has information which would normally be written. */ #define SEC_NEVER_LOAD 0x200 `NOLOAD' The section should be marked as not loadable, so that it will not be loaded into memory when the program is run. case noload_section: flags &= ~SEC_LOAD; flags |= SEC_NEVER_LOAD; What happens when an output section is marked as NOLOAD? From the linker manual, it seems implies that the output section won't be loaded into memory, but may still occupy space in file. But linker comments say that the output section is ignored. But we got [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00400090 000090 00058c 00 AX 0 0 16 [ 2] .bs.required PROGBITS 0040061c 00061c 000004 00 0 0 1 [ 3] .bs.server.name PROGBITS 00400620 000620 00000e 00 W 0 0 1 [ 4] .bs.server.servic PROGBITS 0040062e 00062e 000017 00 W 0 0 1 [ 5] .rodata NOBITS 00400645 00061c 000003 00 WA 0 0 1 [ 6] .trampoline PROGBITS 00401000 000645 0004c0 00 X 0 0 1 [ 7] .data.server NOBITS 00400648 00061c 00000c 00 WA 0 0 1 [ 8] .stab PROGBITS 00000000 000b08 0018b4 0c 9 0 4 [ 9] .stabstr STRTAB 00000000 0023bc 007404 00 0 0 1 [10] .shstrtab STRTAB 00000000 0097c0 000081 00 0 0 1 [11] .symtab SYMTAB 00000000 009a4c 001da0 10 12 419 4 [12] .strtab STRTAB 00000000 00b7ec 000ed0 00 0 0 1 ./ld-next -m elf_i386 -o next -T bss.lds attention.o libbss.a objdump -s -j .bs.server.name attention.o attention.o: file format elf32-i386 Contents of section .bs.server.name: 0000 41747465 6e74696f 6e536967 6e00 AttentionSign. objdump -s -j .bs.server.name next next: file format elf32-i386 Contents of section .bs.server.name: 400620 00000000 00000000 6e536967 6e00 ........nSign. objdump -s -j .data.server attention.o attention.o: file format elf32-i386 Contents of section .data.server: 0000 00000000 00000000 00000000 ............ That is linker writes out the .data.server section marked with SHT_NOBITS and overrides the next section.
A patch is posted at http://sourceware.org/ml/binutils/2007-12/msg00150.html
Fixed by http://sourceware.org/ml/binutils/2007-12/msg00152.html
Thanks a lot!