Debugging small OS kernels (part 6)

(Continued from part 5)

To be perfectly honest, I’d say that this operating system might suffice as a better alternate to the Minix that’s often used in schooling environments. I say that because Minix has a LOT bigger code base. A bigger codebase is more difficult to fully wrap your neurons around. Alternatively, maybe this OS could be the intro, followed by Minix or some other more traditional system. I don’t know how the author of the Visopsys OS would feel about that. I think he’s a perfectionist, and wants all the t’s crossed and i’s dotted first.

I think the kernel and its OS is fine, but hey – I’m in it just for the fun. The system could do better with a little more advanced networking capability. Maybe a GSOC project would be good for that?


I mentioned back on page four that I’d like to profile the execution of the kernel running under QEMU. Unfortunately, it’s not quite as easy as I’d like it to be. I’ve looked around the net for ideas, but most of them involve building a special kernel, with various functions built into it for profiling. That’s exactly what I wanted to avoid. We don’t have direct access to the kernel when it’s running under Qemu. Directly running a profiling tool, or something like Valgrind, isn’t feasible. However; it is possible to run profiling on QEMU itself.

QEMU, if compiled with the –enable-gprof option, will generate a gmon.a file when it runs, and a profile output can be generated using the gprof tool, the gmon.a file, and the original executable.

There are only a few references to gprof profiling QEMU on the web, so I think it’s a pretty arcane thing to do. The question I’m asking (now in my head) is whether or not I could extract any useful data.

By pressing the mouse-grab keys (usually alt+ctl) and pressing “shift 2” – the QEMU monitor screen can be accessed. I typed “info profiling” into the monitor console, but the results were uninteresting. Supposedly, it is possible to use the monitor command “info irq” to get an idea about which interrupts were issued, and with what frequency. That could be helpful in the current case, where we’re trying to diagnose interrupt issues. The problem for me is that, when I type “info irq” into the monitor console, it informs me that irq info capability has not been compiled into QEMU. I didn’t see an option for doing so in the configure help text. So, maybe it’s depreciated.

Later …

I spent an afternoon compiling QEMU to generate profiling data (by compiling with profiling options):

./configure --prefix=/usr --target-list=i386-softmmu --prefix=/usr --enable-debug --extra-cflags=-pg --enable-gtk --enable-gprof --enable-profiler --static

I was able to get profiling information after executing QEMU for about five or ten seconds:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 97.73      5.60     5.60                              ppoll
  0.35      5.62     0.02      768     0.03      0.03  vga_draw_line24_32
  0.35      5.64     0.02                              __lll_lock_wait
  0.35      5.66     0.02                              clock_gettime
  0.17      5.67     0.01   459182   0.00     0.00  qemu_clock_get_ns
  0.17      5.68     0.01    28256    0.00     0.00  subpage_register
  0.17      5.69     0.01     6791     0.00     0.00  phys_map_node_alloc
  0.17      5.70     0.01                              __errno_location
  0.17      5.71     0.01                              bcmp
  0.17      5.72     0.01                              g_ptr_array_remove_range
  0.17      5.73     0.01                              malloc_consolidate
  0.00      5.73     0.00  6783929     0.00     0.00  int128_make64
  0.00      5.73     0.00  4430429     0.00     0.00  qemu_loglevel_mask

It’s a little like debugging or profiling from the bottom up (as adverse to debugging with GDB from the top down). At this point I realized I was going nowhere with the gprof approach. The kernel, which is ultimately what we want to profile, requires re-compilation with the -pg option. But, recompiling the visopsys kernel with the -pg option resulted in:

Error... /...src/kernel/kernelBus.c:61: undefined reference to `mcount' obj/kernelBus.o: In function `kernelBusGetTargets':

A message post on the web gave the reason:

“There is no workaround. using the -pg option of gcc emits code that assumes helper functionality and special startup code provided by glibc.”

This info was found at:

I received this as bad news for our gprof profiling hopes. Visopsys uses its own C library, which has no such functionality as mcount. In terms of profiling, we’re back to square one … unless we’d want to add mcount() to Visopsys’s small C library. LOL – Maybe that wouldn’t be so hard to do?

Go to segment 7 of the article

Note: Visopsys is a project of, and owned by J. Andrew McLaughlin, at These pages are not affiliated with the author or website.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.