Initial commit - Begun rewrite of website generator

pages/2013-08-22-Virtual-File-System.md

@@ -0,0 +1,94 @@
+layout: post
+title: "Virtual File System"
+subtitle: "and a weird weird bug."
+tags: [osdev]
+
+I was planning to start this post with talking about how I was not very
+satisfied with my VFS layer and how I would like to rewrite it. But then
+I rewrote it instead... and ran into a really weird bug.
+
+### The bug
+I'll start with the bug, since it doesn't have anything to do with the
+VFS, but perhaps someone could help me if I write it down.
+
+So, I was happily coding away when I decided to run my emulator as
+usual. Since I develop exclusively in a terminal environment right now
+my setup for testing is four panes in tmux.
+
+- One pane runs qemu and displays its output.
+- One pane controls the qemu terminal through telnet.
+- One pane displays the serial output of qemu.
+- One pane runs gdb connected to qemu.
+
+Qemu is setup to do nothing until I write 'c' in either the terminal or
+gdb to allow me to setup breakpoints and such. Only this time, the qemu
+pane closed immediately before I could do anything at all.
+
+I tried again, with the same results. And again in a desperate display
+of what Einstein allegedly called madness.
+
+What was the problem? It obviously couldn't be anything in my code. My
+code didn't even have time to start running!
+
+After a while I reverted my recent changes anyway, and the testing setup
+ran flawlessly.
+
+What? But my code didn't even run!
+
+I reapplied my changes one at a time and found the line that caused the
+problem.
+
+	int i = 0;
+
+What?? That's it? Declaring a variable?
+
+Anyway. I changed my code about to do the same thing in another way.
+Debugging worked like a charm, but there was some unexpected behavior.
+The best way to nail it down seemed to be by printing a short string
+whenever a function was run. And qemu crashed
+
+What??? Does my emulator hate running working code?
+
+Ok. I've had problems with string before. I ran objdump, commented out
+the string and ran objdump again and compare the sections. They were
+probably overlapping some page border and causing some problems I didn't
+catch with my last linking script update. There really shouldn't be any
+problems left, but anyone can be wrong. Nothing obvious, though... but when I ran the emulator again, it
+crashed.
+
+What???? But I commented the problem out. Didn't I?
+
+Removing the commented line fixed the problem.
+
+What????? A comment?
+
+Next I tried running only qemu, without the other panes. It worked like
+a clock. Starting the terminal console; no problem. Starting gdb...
+crash! Hm...
+
+Removing the `-ggdb` flag from my compiling worked. `-g1`  worked `-g2`
+did not...
+
+I have a `.gdbinit` file in my code root directory, which makes gdb load
+debug symbols and attach automatically. It also sets some useful debug
+breakpoints, like whenever I encounter unsolvable page faults. It turns
+out the breakpoints were the culprit. If I didn't set them, everything
+ran fine.
+
+Now I was getting somewhere. I thought.
+
+After running both gdb and qemu through gdb and actually plowing through
+the DWARF information from `objdump -w`. I finally gave up.
+
+My conclusion:
+This is either a bug in gcc, a bug in gdb or a bug in qemu. To me the
+third alternative seems the likeliest by far.
+My guess is that there's a but in qemus gdb stubs.
+
+If you heard about this bug or experienced it yourself or just have any
+guesses, please let me know.
+
+### VFS
+Oops.. this grew long... Let's take the VFS some other time, shall we?
+
+