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.

    :::c
    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?