96 lines
3.3 KiB
Markdown
96 lines
3.3 KiB
Markdown
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?
|
|
|
|
|