Typed the answers
This commit is contained in:
parent
602e40c09c
commit
83d2c4fa37
78
answers.txt
Normal file
78
answers.txt
Normal file
|
@ -0,0 +1,78 @@
|
|||
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
|
||||
|
Loading…
Reference in a new issue