Fiasco: What's happening

[Michael Hohmuth]

Dear readers of the L4-Hackers mailing list,

first, a big ``Thank you!'' to all who have sent congratulations, best
wishes, and even bug reports and code contributions!  We really
appreciate your interest!

This message is intended to plug this mailing list a bit.

Currently, people prefer to send their questions and problem reports
to me privately instead of publicly on this mailing list.  This is OK,
but I do invite you to discuss Fiasco on this list so that other
people can see what's going on, learn, and maybe even contribute.

(Otherwise, I ask you to at least Cc your messages to
<fiasco-core at os.inf.tu-dresden.de> so that the other members of Team
Fiasco can follow the discussion.)

To initialize you with some current information, I'm now going to post 
a summary of what is happening so far:

It seams that the Fiasco build process is quite dependent on our
current build environment: Gcc-2.7.2.3, Binutils-2.9.1.  I am planning
to switch this to Egcs-1.1 soon (and to make Fiasco more portable to
other compiler versions in the process).  One contributor has sent
patches that make Fiasco compile with Egcs (thanks again!), and I'm
going to release an update as soon as some problems with them are
sorted out: Egcs doesn't seem to like inline assembly very much,
especially in template functions (this even leads to an internal
compiler error) and when using lots of register constraints.

Some people have experienced crashes in the early kernel boot process.
That's why, here are some hints at debugging:

Fiasco can be source-level-debugged using a remote debugger running on
a second machine via a serial connection: Just connect one of your
test machine's serial ports (default: COM2) to your development host
using a null-modem cable.  Edit fiasco/src/.gdbinit to match your
host's serial port, remove the "-nowait" boot option from your GRUB
config file, reboot Fiasco, and start your GDB (or your favorite
GDB-based debugger) when the "KDB: init" message appears.  You can
then set breakpoints, continue the execution, and even interrupt
Fiasco by typing Control-C in the debugger.

Here are some useful boot options for Fiasco (`main'):

- "-nowait" removes the initial "KDB: init" breakpoint.  The
  installation instructions on the Fiasco web site recommend this
  option; if you plan to do some serious debugging, you shouldn't use
  it.

- "-nokdb" disables the kernel debugger.  Should Fiasco raise an
  exception, it will just dump its register contents and die.

- "-comspeed n" will set the rate of the serial interface to n
  bytes/second.  115200 bytes/second is the default.

- "-comport n" will use COMn for serial communication. COM2 is the
  default.

- "-hercules" will output kernel messages to a Hercules (or MGA)
  screen instead of the default VGA console.

- "-serial" will additionally output kernel messages to the serial
  interface; this can save you copying kernel messages by hand.  If
  "-nokdb" is also enabled, you can use a terminal program on the host
  to control Fiasco.  If you are connected to a remote GDB, messages are
  copied to GDB's console.

- "-profile" will profile the kernel; you need to compile it with
  "-DPROFILE" for this to work.  When you terminate Fiasco (e.g.,
  using the remote debugger), the profiling information is printed
  in uuencoded 4.4BSD gmon.out format to the serial interface; you can 
  capture it using a terminal program.

  Unfortunately, current versions of GNU `gprof' don't understand the
  4.4BSD gmon.out format; the next version hopefully does.  I've sent
  a patch to the `gprof' maintainer (the patch is also available on
  request from me).

There are some more options dealing with interrupt allocation for user
threads, but they are hardly relevant for anyone.

That's it for today!

Happy hacking,
Michael
-- 
hohmuth at innocent.com, hohmuth at inf.tu-dresden.de
http://home.pages.de/~hohmuth/