79 lines
2.9 KiB
Plaintext
79 lines
2.9 KiB
Plaintext
|
CSCI-352 Project 1
|
||
|
|
Submitted by: Simon Kadesh, Freya Murphy
|
||
|
|
|
||
|
|
|
||
|
|
Question 1:
|
||
|
|
- Set up base system state (stack, registers, etc.)
|
||
|
|
- Disable non-maskable interrupts
|
||
|
|
- Enables the A20 line
|
||
|
|
- Loads an IDT
|
||
|
|
- Loads a GDT
|
||
|
|
- Enters protected mode
|
||
|
|
- Long jump into segment 15 (probably a code segment?) -- Properly enter
|
||
|
|
protected mode
|
||
|
|
- Setting up protected mode segment registers (point everything at segment 16)
|
||
|
|
|
||
|
|
|
||
|
|
Question 2:
|
||
|
|
A) The CPU first starts executing 32 bit code after a long jump into a 32 bit
|
||
|
|
segment after setting a GDT (Long jump is at 0x7c2d)
|
||
|
|
B) The last instruction is a call into the kernel. It occurs at 0x7d71
|
||
|
|
C) The first instruction of the kernel is at 0x10000C
|
||
|
|
D) It reads the elf program header in the kernel. There is no file system on
|
||
|
|
the image that we build, so the kernel begins at the first page of the disk
|
||
|
|
|
||
|
|
|
||
|
|
Question 3:
|
||
|
|
The first instruction that would cause a problem would be the first instruction
|
||
|
|
that uses an absolute address calculated based on the link address. In this
|
||
|
|
case, that would be the long jump into protected mode in the bootloader. When
|
||
|
|
we changed the link address in boot/Makefrag, it caused the bootloader to jump
|
||
|
|
into arbitrary garbage code, rather than the kernel.
|
||
|
|
|
||
|
|
|
||
|
|
Question 4:
|
||
|
|
As the BIOS enters the bootloader the 8 words at 0x100000 are all zero.
|
||
|
|
When the bootloader enters the kernel, the are equal to:
|
||
|
|
0x1badb002 0x00000000 0xe4524ffe 0x7205c766
|
||
|
|
0x34000004 0xa000b812 0x220f0010 0xc0200fd8
|
||
|
|
These are the first 8 words of the kernel .text section
|
||
|
|
(including a multiboot 1 header)
|
||
|
|
|
||
|
|
|
||
|
|
Question 5:
|
||
|
|
The mov %eax, %cr0 is what enables virtual memory mapping. Thus the jump
|
||
|
|
from the initial stub in entry to relocated (which the kernel believes is
|
||
|
|
at 0xf0...) will fail because there is nothing at 0xf0...
|
||
|
|
|
||
|
|
|
||
|
|
Question 6:
|
||
|
|
A) console.c exports functions for printing characters to the serial and
|
||
|
|
parallel ports, and the CGA display printf.c has a function putch calls
|
||
|
|
cputchar (console.c) which calls cons_putch which calls the functions
|
||
|
|
to output a character to each of the aforementioned devices.
|
||
|
|
B) An arbitrary signed 32 bit decimal value will be printed. This is because
|
||
|
|
it will try to read the next VA_ARG, which has not been passed.
|
||
|
|
C) You would need to make the format string the last argument. That way the
|
||
|
|
format string is at the top of the stack when we are popping arguments.
|
||
|
|
This is necessary because the format string must be the first value we pop
|
||
|
|
as we use it to determine how many arguments there are.
|
||
|
|
|
||
|
|
|
||
|
|
Question 7:
|
||
|
|
The kernel initializes its stack to 0xf0103000 (virtual address), it reserves
|
||
|
|
memory by reserving 8 pages worth of space in the binary that gets built.
|
||
|
|
(32768 bytes). The stack starts at the highest address in this block of memory
|
||
|
|
and grows down
|
||
|
|
|
||
|
|
|
||
|
|
Question 8:
|
||
|
|
Each level of test_backtrace pushes 8 32-bit words to the stack.
|
||
|
|
Those words are:
|
||
|
|
1 ) the base pointer
|
||
|
|
2 ) whatever was in %ebx
|
||
|
|
3 ) its own first argument
|
||
|
|
4 ) the address of the format string for cprintf
|
||
|
|
5-7) 0
|
||
|
|
8 ) the return address
|
||
|
|
|