James Molloy's Tutorial Known Bugs: Difference between revisions

Several sources - including this Wiki - point to [http://www.jamesmolloy.co.uk/tutorial_html/ James Molloy's Roll your own toy UNIX-clone OS] Tutorial as a starting point. This is wellfine, but the tutorial has some well-known weak points that cause trouble for people again and again. It's not uncommon that well-established members traced back mysterious bugs to early parts of their operating systems based on this tutorial. Nonetheless, it's one of the best introductory tutorials out there even if it has the occasional landmine. This article is meant to preempt issues arising from following the tutorial and to aid those that have encountered such problems. It is generally recommended to be sceptical of its advise on how to design your kernel and compare its information against this wiki. Some issues are quite subtle and only experts will recognize them.

The tutorial states that the <tt>__cdecl</tt> calling convention is used. This is, however, a Windows term. and yourYour cross-compiler uses a similar calling convention but it is called the System V ABI for i386. It is advisable to understand this calling convention in depth, especially parts about how the parameters on the stack are clobbered and how structure parameters are passed. This will be very useful later and will help you avoid a later subtle bug. The function call example in 2.3 neglects to add 12 to esp following the call instruction, andso the three parameters are never thus popped.

The gccGCC documentation mentions that the <tt>memset</tt>, <tt>memcpy</tt>, <tt>memmove</tt> and <tt>memcmp</tt> functions must always be present. The compiler uses these automatically for certain optimization purposes and even code that doesn't use them can automatically generate calls to them. You should add them at your earliest convenience.

== Problem: ISR 17 and 3021 have error codes ==

The interrupt handling code in the downloadable code have a bug where it handles ISR 17 and 3021 by pushing a fake error code, but the CPU does push error codes here.

This attribute packs the associated structure. This is useful in a few cases, such as the idtIDT and gdtGDT code (actually just the idtIDT, gdtGDT and tssTSS pointers). However, the tutorial tends to randomly attach it to every struct parameter, even where it isn't even needed. It is only needed where you badly want aligned structure members, it doesn't do anything if all the structure members were already naturally aligned. Otherwise, the compiler will automatically insert gaps between structure members so each begins at its own natural alignment.

The paging code isn't terribly good and it is worth it to fully understand paging and design it all yourself. Paging code tends to be quite ugly, but it'll probably be decent after your fifth design revision. There is no need to always re-enable paging in <tt>switch_page_directory</tt>, it is likely best to have a special function the first time paging is enabled. The inlineInline assemblyAssembly in 6.4.5. doesn't need to be volatile as it is simply reading a memory value, which has no side-effects and it is acceptable if the compiler optimizes it away if the value is never used.

=== Inline assemblyAssembly optimiser problem with gccGCC 4.8 ===

As mentioned above, writing inlineInline assemblyAssembly can be tricky. The original inlineInline assemblyAssembly is this:

Note how the eaxEAX register is assigned to the ecxECX register. However, later on the ecxECX register is assigned to ebpEBP register. The reason for this is that the optimizer was using the eaxEAX register to store the eipEIP variable and the ecxECX register to store the ebpEBP variable. This results in the eipEIP variable being assigned to the ecxECX register ''as well as'' the ebpEBP register. This leads to a subsequent '''ret''' statement sending the cpuCPU to some invalid memory location.

A way to fix this is to remove the inlineInline assemblyAssembly by, for example adding this to '''process.cs''':

; * Put a dummy value (0x12345) in EAX so that above we can recogniserecognize that we've just

mov ecx, [esp+4] ; eipEIP

mov ebp, [esp+12] ; ebpEBP

mov esp, [esp+16] ; espESP

and replace the inlineInline assemblyAssembly with:

=== Problem 2: Don't forget to allow interrupts in user mode in idt_set_gate ===

=== Problem 4: MisingMissing documentation around set_kernel_stack ===

=== Problem 5: Operator precedencefind_smallest_hole() bug in find_smallest_holeheap code causing fork() to page fault ===

There is an operator precedenceThis bug infrom <tt>find_smallest_hole()</tt>the thatheap willchapter causemay badnot allocationshit andyou memoryuntil overwritesnow. ifThe attempting to fork. Thisbug results in the newly allocated <tt>kernel_stack</tt> messing up the page directory, causing <tt>clone_directory()</tt> to fail in <tt>fork()</tt>. See the heap section above for the details.