(Continued from part 4)
Are we having fun yet?
Take your pick of GUI, or don’t use any at all! I’ve done as much “conventional” type programming with either of them (now all the vim guys can stick out their tongues). I started my time in the programming world, using Unix, but then spent a couple decades in the corporate Windows application development world (DOS too!). I got hooked on these kinds of fancy GUIs. I’ve written all kinds of “system” level (but still userland) apps with them … things like web and DNS daemons, mail daemons, and the like. Now, it’s time to pick on the kernels.
The kernel I used had been compiled with the debug info (-g option). But – I never looked for the optimization options, so (as you can see) – the compiler has used them to our debugging disadvantage. We’ll recompile the kernel, and take out optimizations. That will be easy, because Anjuta compiles the whole shebang (kernel, drivers, and programs) – on the imported source code base, with no modifications. The whole operating system, including applications, can be compiled in Anjuta with a single click.
In the Anjuta IDE, we can select the Makefile.include file, remove the -Os optimization, and rebuild the entire operating system by selecting “Build project” from the build menu. That will deposit a nice new shiny kernel in the ~/topsrc/build directory. In the next step, we need to create a new ISO image to launch inside Qemu, and that contains the new kernel. To do that, we go to the utils directory, and type:
The result should be:
Making Visopsys CD-ROM IMAGE file
– doing INTERIM version 2014-12-21 (use -r flag for RELEASES)
Making/copying boot floppy image… Done
Copying build files… Done
Copying doc files… Done
Creating ISO image… Done
File is: visopsys-2014-12-21-iso.zip
Great! Note that on Debian Wheezy you’ll have to add a symlink, or the mkisofs won’t be found:
ln -s /usr/bin/genisoimage /usr/bin/mkisofs
The graphic (above) shows Anjuta compiling the entire operating system (well – with the help of the GNU compiler!).
At this point, we can launch QEMU with the new ISO, in a “stopped” state:
qemu -hda ./visopsys1.img -cdrom ./visopsys-2014-12-21.iso -boot d -s -serial stdio -S
Before we launch a remote debugging session from inside of Anjuta, we’ll copy the new kernel to our start directory, and make a new syms file from it:
objcopy --only-keep-debug ./visopsys ./visopsys.syms
We can load this file, as before, in the case where Anjuta doesn’t pick up the info by itself. Anjuta has improved a lot over the years. I think it’s probably never necessary to do it manually anymore. Debugging kernels is a little different than debugging regular applications, so sometimes Anjuta needs a little help. (I’ve been an Anjuta user since its original author first published it, and named it for his girlfriend). Now, the GNU people look after it.
I’d care to comment about Visopsys. It’s a useful operating system, from the standpoint of educating oneself about OS internals. But – it’s not a primitive operating system such as one might encounter in a college “build your own from scratch” course. It’s far more functional than any such thing as that. It has a very nice, working windowing system, as well as a score of applications, editors, system utilities, and the like. It has an embryonic networking subsystem. Typically, an OS that could be compiled easily, including its extended user-land, in an Anjuta/gdb/gcc environment such as has been described on this page, would never have such functionality as this OS does.
Note: Visopsys is a project of, and owned by J. Andrew McLaughlin, at http://www.visopsys.org. These pages are not affiliated with the author or website.