We see some weird address generation when using ld and objcopy to generate parts
of bios images (upcoming LinuxBIOS version 3)
The first thing that is required is the reset vector. It's 16
bytes at 0xfffffff0 (aliased to f000:fff0 in real mode). It jumps into
the real code which is placed at 0xffffe000 (0xe000 in the current segment).
--------- 8< reset.s --------------------------
SEGMENT_SIZE = 0x10000
RVECTOR = 0x00010
.code16
.globl _start
_start:
jmp SEGMENT_SIZE-(0x1f00 +0xf0 +RVECTOR)
.byte 0
.ascii "2007/02/01"
.word 0
----------------- 8< --------------------------
I build it with:
as reset.s -o reset.o
and link it:
ld -Ttext 0xfffffff0 reset.o -o reset.elf
objcopy -O binary -S reset.elf reset.bin
Now I disassemble it:
ndisasm -o 0xfffffff0 reset.bin | head -1
FFFFFFF0 E9FEDF jmp 0xdff1
Oops. It is obviously wrong. But why?
Alternatively I omit the objcopy step but I basically do the same (do I?):
ld -Ttext 0xfffffff0 -s --oformat binary reset.o -o reset.bin
ndisasm -o 0xfffffff0 reset.bin | head -1
FFFFFFF0 E90DE0 jmp 0xe000
Phew. It works here. But why? What's the difference?
We don't really want to use the second version, because the intermediate
elf binary is nice to dump a symbal table using nm -e reset.elf. People
are sometimes heavily relying on this:
0000000000000010 a RVECTOR
0000000000010000 a SEGMENT_SIZE
00000000fffffff0 T _start
Version is binutils 2.17.50.0.5 from OpenSUSE 10.2 but I other people using some
version of RH FC seem to see the same problem.
--
Summary: LD + objcopy generate wrong jump address
Product: binutils
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: stepan at coresystems dot de
CC: bug-binutils at gnu dot org
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://sourceware.org/bugzilla/show_bug.cgi?id=3958
------- 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
