On a.out targets, when ld links an executable containing no symbols and no
relocations, the last byte of the last section is overwritten with a zero byte.
However, it is rarely a problem, because most executables contains relocations,
and the sections are padded with filler bytes.
This scenario shows how to reproduce this bug on a m68k-netbsd target.
I found that on this target, linking an executable containing only a few
instructions will result in a text section padded to exactly 8160 bytes.
Thus, I generate a text section having exactly this size, to avoid padding.
$ cat nop.s
.rept 4080
nop
.endr
$ as nop.s -o nop.o
$ ld nop.o -o nop -s
$ objdump -d nop |tail
3fec: 4e71 nop
3fee: 4e71 nop
3ff0: 4e71 nop
3ff2: 4e71 nop
3ff4: 4e71 nop
3ff6: 4e71 nop
3ff8: 4e71 nop
3ffa: 4e71 nop
3ffc: 4e71 nop
3ffe: 4e00 047000
The last byte is 0 instead of 0x71
I found the cause of this problem at the end of the file bfd/aoutx.h
in the function NAME (aout, final_link)
/* Write out the string table, unless there are no symbols. */
if (abfd->symcount > 0)
{
if (bfd_seek (abfd, obj_str_filepos (abfd), SEEK_SET) != 0
|| ! emit_stringtab (abfd, aout_info.strtab))
goto error_return;
}
else if (obj_textsec (abfd)->reloc_count == 0
&& obj_datasec (abfd)->reloc_count == 0)
{
bfd_byte b;
file_ptr pos;
b = 0;
pos = obj_datasec (abfd)->filepos + exec_hdr (abfd)->a_data - 1;
if (bfd_seek (abfd, pos, SEEK_SET) != 0
|| bfd_bwrite (&b, (bfd_size_type) 1, abfd) != 1)
goto error_return;
}
The else case is the cause of this problem.
Removing it fixes the bug.
But that code may be useful for something ?
--
Summary: ld corrupts a.out text sections
Product: binutils
Version: 2.18 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: vincent dot riviere at freesbee dot fr
CC: bug-binutils at gnu dot org
GCC target triplet: m68k-netbsd
http://sourceware.org/bugzilla/show_bug.cgi?id=4694
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
