define startup stack in linker script, not assembly
This commit is contained in:
parent
05de14800b
commit
b202eca0cc
@ -97,6 +97,7 @@ EOF
|
||||
env["LIBS"] += %w[gcc]
|
||||
env["OBJDUMP"] = "i686-elf-objdump"
|
||||
env.Program("^/hos.elf", glob("src/**/*.{S,c}"))
|
||||
env.depends("#{env.build_root}/hos.elf", "src/link.ld")
|
||||
env.Disassemble("^/hos.elf.txt", "^/hos.elf")
|
||||
env.EfiImage("build/hos-efi.img", %w[^/hos.elf])
|
||||
env.BiosImage("build/hos-bios.img", %w[^/hos.elf])
|
||||
|
38
src/boot.S
38
src/boot.S
@ -1,21 +1,3 @@
|
||||
/*
|
||||
The multiboot standard does not define the value of the stack pointer register
|
||||
(esp) and it is up to the kernel to provide a stack. This allocates room for a
|
||||
small stack by creating a symbol at the bottom of it, then allocating 16384
|
||||
bytes for it, and finally creating a symbol at the top. The stack grows
|
||||
downwards on x86. The stack is in its own section so it can be marked nobits,
|
||||
which means the kernel file is smaller because it does not contain an
|
||||
uninitialized stack. The stack on x86 must be 16-byte aligned according to the
|
||||
System V ABI standard and de-facto extensions. The compiler will assume the
|
||||
stack is properly aligned and failure to align the stack will result in
|
||||
undefined behavior.
|
||||
*/
|
||||
.section .bss
|
||||
.align 16
|
||||
stack_bottom:
|
||||
.skip 16384 # 16 KiB
|
||||
stack_top:
|
||||
|
||||
/*
|
||||
The linker script specifies _start as the entry point to the kernel and the
|
||||
bootloader will jump to this position once the kernel has been loaded. It
|
||||
@ -25,25 +7,7 @@ doesn't make sense to return from this function as the bootloader is gone.
|
||||
.global _start
|
||||
.type _start, @function
|
||||
_start:
|
||||
/*
|
||||
The bootloader has loaded us into 32-bit protected mode on a x86
|
||||
machine. Interrupts are disabled. Paging is disabled. The processor
|
||||
state is as defined in the multiboot standard. The kernel has full
|
||||
control of the CPU. The kernel can only make use of hardware features
|
||||
and any code it provides as part of itself. There's no printf
|
||||
function, unless the kernel provides its own <stdio.h> header and a
|
||||
printf implementation. There are no security restrictions, no
|
||||
safeguards, no debugging mechanisms, only what the kernel provides
|
||||
itself. It has absolute and complete power over the
|
||||
machine.
|
||||
*/
|
||||
|
||||
/*
|
||||
To set up a stack, we set the esp register to point to the top of the
|
||||
stack (as it grows downwards on x86 systems). This is necessarily done
|
||||
in assembly as languages such as C cannot function without a stack.
|
||||
*/
|
||||
mov $stack_top, %esp
|
||||
mov $_stack_end, %esp
|
||||
|
||||
/*
|
||||
This is a good place to initialize crucial processor state before the
|
||||
|
@ -20,6 +20,14 @@ SECTIONS
|
||||
*(.data)
|
||||
}
|
||||
|
||||
_stack_size = 16K;
|
||||
.stack (NOLOAD) : ALIGN(4K)
|
||||
{
|
||||
_stack_start = .;
|
||||
. = . + _stack_size;
|
||||
_stack_end = .;
|
||||
}
|
||||
|
||||
.bss BLOCK(4K) : ALIGN(4K)
|
||||
{
|
||||
*(COMMON)
|
||||
|
Loading…
x
Reference in New Issue
Block a user