[gentoo-soc] Plan 9 From Gentoo: Weekly Progress Report #12

Hi, all.

Plan 9 From Gentoo is a 2011 GSoC project to overlay a Plan 9 inspired userspace on top of a Linux base system.

Project page: http://soc.dev.gentoo.org/~rps/plan9/
LiveCD image: http://soc.dev.gentoo.org/~rps/plan9-download/plan9-from-gentoo-x86-minimal.iso

I spent most of this week working on nine (https://github.com/robertseaton/nine), a port of Glendix's functionality into a userspace binary. I also generated a number of new Plan 9 From Gentoo images and added a link to the project overlay on the project page.

All of the newly generated Plan 9 From Gentoo images are garbage since the release engineering team has _finally_ fixed the issue with auto-login on the official liveCD images, something which I had to work around when writing the code that handles Plan 9 From Gentoo's current boot process. Unfortunately, the fix breaks Plan 9 From Gentoo's boot. I will have to look into modifying Plan 9 From Gentoo's boot process during the upcoming week.

As far as nine is concerned, I managed to fix an issue with the code where a seemingly invalid entry pointer was being read from the binary's header information. It was tricky to catch the bug, since some of the header information was valid. It turned out that the issue was my failure to realize that 'long', on x86_64, is 8 bytes long, while the code from Glendix assumes that you're compiling for i686 and thus long is 4 bytes long. The issue was compounded by the fact that the magic value used to verify that a binary is, in fact, a valid Plan 9 binary was eb 01 00 00, which correctly translates to 491 when read as either an 8 byte value or a 4 byte value! When I realized this, it was readily apparent to me that I had failed to account for differences in the size of long on differing architectures and I fixed the bug.

I also ported the code from Glendix that "simulates" the TOS, a data structure used on Plan 9 to facilitate IPC. It is hard to be sure whether this code is functioning correctly or not.

I'm running into an issue with nine where I would like to verify that I have mmap'd in the correct data and text segments from the Plan 9 binary. It seems to me that it would be very useful if I could somehow obtain a snapshot of a Plan 9 executable's address space when it is first executed on top of a Glendix patched kernel. I could then compare this snapshot to a snapshot of the address space of an executable being run by nine and verify that the correct segments are mapped in at their respective locations. If anyone knows of a way in which I could do something like this, please contact me. Currently, I'm thinking that there may be a way in which to force a running program to generate a core dump and, if I could somehow trigger that signal at the very start of a program, I might be able to gather the information that I'm looking for.

Once I have verified that the correct TEXT and DATA segments are loaded in to memory, I can proceed with writing the code to set up the userspace stack for the Plan 9 program. This will be tricky since much of the Glendix code to accomplish this relies on constructs that are specific to code running in kernel space and not applicable to a userspace program. I'm confident that it is possible, it's just a manner of determining what needs to be in memory and where.

rps