I'm writing a Multiboot compliant ELF executable containing my 32-bit kernel. My primary problem is that I'm receiving a series of linker errors while producing my executable:
relocation truncated to fit: R_386_16 against `.text'
Linker Script, Code and Build script below
I have decided to try implementing VESA VBE graphics in my OS. I found an existing VESA driver in the OSDev forum and I tried to integrate it into my own OS. I tried adding it to my source directory, assembled it with NASM and linked it into a final executable with LD. The specific errors I received were:
vesa.asm:(.text+0x64): relocation truncated to fit: R_386_16 against `.text'
obj/vesa.o: In function `svga_mode':
vesa.asm:(.text+0x9d): relocation truncated to fit: R_386_16 against `.text'
vesa.asm:(.text+0xb5): relocation truncated to fit: R_386_16 against `.text'
obj/vesa.o: In function `done':
vesa.asm:(.text+0xc7): relocation truncated to fit: R_386_16 against `.text'
The lines causing the error (in order) are the following:
mov ax,[vid_mode]
mov cx,[vid_mode]
mov bx,[vid_mode]
jmp 0x8:pm1
I have also commented the lines with "Linker error"
Here is the file (vesa.asm):
BITS 32
global do_vbe
save_idt: dd 0
dw 0
save_esp: dd 0
vid_mode: dw 0
do_vbe:
cli
mov word [vid_mode],ax
mov [save_esp],esp
sidt [save_idt]
lidt [0x9000] ;; saved on bootup see loader.asm
jmp 0x18:pmode
pmode:
mov ax,0x20
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax
mov ss,ax
mov eax,cr0
dec eax
mov cr0,eax
jmp 0:realmode1
[bits 16]
realmode1:
xor ax,ax
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax
mov ss,ax
mov sp,0xf000
sti
;; first zero out the 256 byte memory for the return function from getmodeinfo
cld
;; ax is already zero! I just saved myself a few bytes!!
mov cx,129
mov di,0x5000
rep stosw
mov ax,[vid_mode] ; Linker error
xor ax,0x13
jnz svga_mode
;; Ok, just a regular mode13
mov ax,0x13
int 0x10
;; we didnt actually get a Vidmode structure in 0x5000, so we
;; fake it with the stuff the kernel actually uses
mov word [0x5001],0xDD ; mode attribs, and my favorite cup size
mov word [0x5013],320 ; width
mov word [0x5015],200 ; height
mov byte [0x501a],8 ; bpp
mov byte [0x501c],1 ; memory model type = CGA
mov dword [0x5029],0xa0000 ; screen memory
jmp done
svga_mode:
mov ax,0x4f01 ; Get mode info function
mov cx,[vid_mode] ; Linker error
or cx,0x4000 ; always try to use linear buffer
mov di,0x5001
int 0x10
mov [0x5000],ah
or ah,ah
jnz done
mov ax,0x4f02 ; Now actually set the mode
mov bx,[vid_mode] ; ; Linker error
or bx,0x4000
int 0x10
done:
cli
mov eax,cr0
inc eax
mov cr0,eax
jmp 0x8:pm1 ; Linker error
[bits 32]
pm1:
mov eax,0x10
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax
mov ss,ax
mov dword esp,[save_esp]
lidt [save_idt]
ret
Main entry file (entry.asm):
extern kmain
extern do_vbe
; Multiboot Header
MBALIGN equ 1<<0
MEMINFO equ 1<<1
;VIDINFO equ 1<<2
FLAGS equ MBALIGN | MEMINFO; | VIDINFO
MAGIC equ 0x1BADB002
CHECKSUM equ -(MAGIC + FLAGS)
section .text
align 4
dd MAGIC
dd FLAGS
dd CHECKSUM
;dd 0
;dd 0
;dd 0
;dd 0
;dd 0
;dd 0
;dd 800
;dd 600
;dd 32
STACKSIZE equ 0x4000
global entry
entry:
mov esp, stack+STACKSIZE
push eax
push ebx
call do_vbe
cli
call kmain
cli
hlt
hang:
jmp hang
section .bss
align 32
stack:
resb STACKSIZE
My linker script:
OUTPUT_FORMAT(elf32-i386)
ENTRY(entry)
SECTIONS
{
. = 100000;
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss) }
}
My build script (Note I am using Cygwin):
cd src
for i in *.asm
do
echo Assembling $i
nasm -f elf32 -o "../obj/${i%.asm}.o" "$i"
done
for i in *.cpp
do
echo Compiling $i
i686-elf-g++ -c "$i" -o "../obj/${i%.cpp}.o" -I ../include --freestanding -fno-exceptions -fno-rtti -std=c++14 -Wno-write-strings
done
for i in *.S
do
echo Compiling $i
i686-elf-as -c "$i" -o "../obj/${i%.S}.o"
done
for i in *.c
do
echo Compiling $i
i686-elf-gcc -c "$i" -o "../obj/${i%.cpp}.o" -I ../include --freestanding
done
cd ..
i686-elf-ld -m elf_i386 -T linkscript.ld -o bin/kernel.sys obj/*.o
If it helps here is the directory structure:
/src Source Files
/include Include files
/obj Object files
/bin Kernel Executable
Reason for the Linker Error
This error you received:
is effectively telling you that when the linker attempted to resolve these relocations within the
.textsection that it was unable to do so because the Virtual Memory Addresses (VMA) it computed could not fit in a 16-bit pointer (_16).If you use
-g -Fdwarfwhen assembling with NASM you can produce more usable output from OBJDUMP using a command likei686-elf-objdump -SDr -Mi8086 vesa.o.-Soutputs source-Dis for disassembly,-rshows the relocation information.The following is the output I get (it differs slightly but the ideas presented here still apply):
I have removed the information that wasn't of any consequence for brevity and replaced it with
...in the output. There is a[bits 16]directive that forces all memory addresses to be 16-bit unless overridden. As an examplec6: R_386_16 .textmeans there is a relocation at offset (0xc6) that is a 16-bit pointer appearing in the.textsection. Keep this in mind. Now review the linker script:The VMA (origin) is 0x100000. This is effectively the origin point for all the code and data in this case. All the addresses generated in the final executable will be over 0xFFFF which is the maximum value that can fit in a 16-bit pointer. This is the reason the linker is complaining.
You can override the default address and operand sizes by specifying DWORD before the label name between the brackets
[and]. An absolute 32-bit FAR JMP can be encoded by specifying DWORD before the operand. These lines:Would become:
If you assemble the revised code and use OBJDUMP as discussed above you get this output (cut for brevity):
The instructions now have a
0x66and0x67prefix added to them and the addresses take 4 bytes in the instruction. Each of the relocations are of typeR_386_32which tells the linker that the addresses to relocate are 32-bits wide.Although the changes in the previous section will eliminate the warnings during linking, when run things may not work as expected (including crashes). On an 80386+ you can generate 16-bit real mode code that uses 32-bit addresses for the data but the CPU has to be put into a mode that allows such access. The mode that allows 32-bit pointers accessed via the DS segment with values above 0xFFFF is called Unreal Mode. OSDev Wiki has some code that could be used as a basis for such support. Assuming the PICs haven't been remapped and are in their initial configuration then the usual way to implement on demand Unreal Mode is to replace the 0x0d Interrupt handler with something that does:
If PIC1 has been remapped so as to not conflict with the x86 exception handling interrupts (int 0x08 to int 0x0f) then steps 1,2,3 no longer apply. Remapping the PICs to avoid this conflict is common place in x86 OS design. The code in the question doesn't do any PIC remapping.
This mechanism won't work if you want to ever use the code in a VM8086 task rather than entering real mode.
DOS's HIMEM.SYS did something similar in the 1980s and you can find a discussion about that in this article if you are interested.
Note : Although I give a general description of using Unreal Mode, I don't recommend this method. It requires more extensive knowledge of real mode, protected mode, interrupt handling.
More Preferred Solution
Rather than using 32-bit data pointers greater than 0xFFFF, and ensuring that the processor is in unreal mode there is a solution that may be easier to understand. One such solution is to copy the real mode code and data from where the Multiboot loader physically loaded into RAM above 0x100000 to the first 64KB of memory memory just above the real mode interrupt vector table (IVT). This allows you to continue using 16-bit pointers because the first 64KB of memory is addressable with a 16-bit pointer (0x0000 to 0xFFFF). The 32-bit code will still be able to access the real mode data if needed.
To do this you will have to create a more complex GNU LD linker script (
link.ld) that uses a Virtual Memory Address (origin point) in lower memory. Address 0x01000 is a good choice. The Multiboot header will still have to be present at the beginning of the ELF executable.One problem that has to be overcome is that the Multiboot loader will read the code and data into memory above 0x100000. One has to manually copy the 16-bit real mode code and data to address 0x01000 before the real mode code can be used. The linker script can help generate symbols to compute the start and end addresses for such a copy.
See the code in the last section for a linker script
link.ldthat does just that, and akernel.cfile that does the copy.With properly adjusted VESA code what you are trying to do should work.
Problems with VESA Code You Found
[bits 16]directive.The author had these comments:
A Complete Example
The following code is a complete implementation of what has been suggested above. Use a linker script and generate real mode code and data and place it starting at 0x1000. The code uses C to set up a proper GDT with 32 and 16-bit Code and Data segments, copies the real mode code from above 0x100000 down to 0x1000. It also fixes the other issues previously identified in the VESA driver code. To test it switches in to video mode 0x13 (320x200x256) and paints part of the VGA color palette to the display 32 bits at a time.
link.ld:gdt.inc:vesadrv.asm:vesadrv.h:gdt.h:gdt.c:multiboot.asm:kernel.c:A simple set of commands to assemble/compile/link the code above into an ELF executable called
multiboot.elf:You can find a copy of the code above on my site. When I run the kernel in QEMU this is what I see: