Lab 1 - boot loader
Part 2: The Boot Loader
Q: At exactly what point does the processor transition from executing 16-bit code to executing 32-bit code?
A: Processor transitions from executing 16-bit code to executing 32-bit code on execution of following instruction:
Q: What is the last instruction of the boot loader executed, and what is the first instruction of the kernel it just loaded?
A: Last instruction of boot loader executed is call of routine in .text section of kernel:
Q: How does the boot loader decide how many sectors it must read in order to fetch the entire kernel from disk? Where does it find this information?
A: Boot loader decides how many sectors to read using information stored in ELF header. The ELF file format is shown in following image:
At the start of main.c, first sector (512 bytes) is loaded from disk. This sector is now in memory starting on location of 0x10000 and contains ELF File Header. First check is whether this is a correct ELF file by checking if magic number (first four bytes) of ELF file are correct:
1 2 3
ELF Program Header address is loaded to
where e_phoff is the offset of program header from the start of the file. Then we store the address of last program header to eph variable:
where e_phnum is the number of entries in program header. Now we simply iterate through program header table and read segments using function readseg giving it 3 arguments:
1 2 3
It’s obvious that read size is rounded to sector size boundary which means that we load more than we really need in most cases.
Exercise 6. Reset the machine (exit qemu and start it again). Examine the 8 words of memory at 0x00100000 at the point the BIOS enters the boot loader, and then again at the point the boot loader enters the kernel. Why are they different?
A: Entry point in kernel is 0xf0100000 which we pass as virtual address to
readseg function which does 0xf0100000 & 0xFFFFFF which gives the address at which we load the program text (0x100000). First 8 words contain first 8 words of kernel program text.
Exercise 8. We have omitted a small fragment of code - the code necessary to print octal numbers using patterns of the form “%o”. Find and fill in this code fragment.
Following fragment is added starting with line 209 in
1 2 3 4
Q: Explain the interface between printf.c and console.c. Specifically, what function does console.c export? How is this function used by printf.c?
cputchar function which is used in
Q: Explain the following from console.c:
1 2 3 4 5 6 7
A: This code does line scrolling if
crt_pos is at last line of crt +
Q: In the following code, what is going to be printed after ‘y=’? (note: the answer is not a specific value.) Why does this happen?
A: Random garbage will be printed since second variable is not specified.
Challenge Enhance the console to allow text to be printed in different colors.
I decided to go with standard ANSI escape sequences to define text foreground and background colors. Full specification can be found here ANSI escape sequence. Defined functions include various screen actions but for text foreground/background coloring I decided to implement just a small subset of whole specification called “Set Graphics Mode”. Following pattern is used to specify color:
Following attributes are defined:
0 All attributes off 1 Bold on 4 Underscore (on monochrome display adapter only) 5 Blink on 7 Reverse video on 8 Concealed on
(in my implementation - text attributes are ignored)
30 Black 31 Red 32 Green 33 Yellow 34 Blue 35 Magenta 36 Cyan 37 White
40 Black 41 Red 42 Green 43 Yellow 44 Blue 45 Magenta 46 Cyan 47 White
ANSI defined colors and CGA colors use different codes so translation table was needed. This table is defined in following array:
1 2 3 4 5 6 7 8 9 10
All changes are done in
lib/printfmt.c file in
To test this feature I added ANSI coloring to one of of cprintf’s:
And the result is:
Exercise 11. Implement the backtrace function as specified above. Use the same format as in the example, since otherwise the grading script will be confused. When you think you have it working right, run make grade to see if its output conforms to what our grading script expects (you should pass the Count and Args tests), and fix it if it doesn’t. After you have handed in your Lab 1 code, you are welcome to change the output format of the backtrace function any way you like.
Calling stack for C programs has following layout:
I created the following C structure to read parameters from calling stack:
1 2 3 4 5
I decided to limit it to 5 function arguments since not a single function in current JOS kernel uses more than 4 - so this should be enough. Now the only problem is how to know when to stop recursive traversing of stack and for that answer, following line is from
So this way - when we reach ebp with value 0 - we know that we should stop traversing stack. This is partial code of traverse:
1 2 3 4 5 6 7
The rest of this exercise is simply printing arguments using:
Exercise 12. Modify your stack backtrace function to display, for each eip, the function name, source file name, and line number corresponding to that eip.
Excellent tutorial on stabs debug format can be found here.
Stabs structure and constants are defined in
inc\stab.h. I decided to do both of those functions in one commit (
036672789b00140a951cc216f4ae8066b4c28a00). Here is the result:
and grade script for this lab is satisfied:
EXTRA point This makes pretty useful backtrace function but I didn’t want to guess how many arguments there are to the function (by default we print 5 of them no matter how many of them function uses) nor arguments names so I decided to use
N_PSYM stab tag to calculate number of arguments and get argument names. Now the same output with this enhancement is a bit more useful:
We can easily spot from this output that
monitor function has one argument named
i386_init has no arguments etc, etc. This will make troubleshooting a bit easier.
This enhancement is in commit (74818a8a7afc72da67f4c43a48a7e6bcd2f73960).