execve() starts to take shape

Despite the lack of a memory allocator and a working file system, I decided to start working on the execve() system call. In its current state, it doesn't load the text and data sections from a file; instead, it uses a hard-coded location for the program code, and it doesn't have a data section. Also, the stack pointer points to a global array variable with a fixed size. However, execve() has rudimentary code to pass arguments and environment variables to the new process image through its stack.

As a result, instead of executing /etc/init as it expects, the kernel's icode() actually executes something entirely different. I took the opportunity to test the argument- and environment-passing mechanism of execve() inside the new user program simply by printing the arguments and environment passed to it. That program essentially consists of this code:

#include <stdio.h>
#include <string.h>

static void println(char *s)
{
 write(2, s, strlen(s));
 write(2, "\n", 1);
}

int main(int argc, char *argv[], char *envp[])
{
 println("This is a user program.");
 
 println("\narguments:");
 for (; *argv; ++argv)
  println(*argv);
 
 println("\nenvironment:");
 for (; *envp; ++envp)
  println(*envp);
 
 return 0;
}

which is a fully-working standalone C program. You can run the above program and see all of the arguments and environment passed to it. Here is the result of running this program in Punix (the text after the copyright and warranty information but before the kernel panic message):



The arguments and environment are those passed to it by icode(). The first argument to the program, "-00000", comes from 2.11BSD (one of many sources I'm using to write Punix). I kept it in there when I transliterated my icode() routine from PDP to 68k assembly language code. When I get a real "init" program I'll change the argument to whatever it expects and accepts as arguments (such as to specify the run level to enter after booting). It will also depend on the (possible) presence of a boot loader that can pass arguments to the kernel and to init. That will be some time in the future, so I won't worry about it for now.

Status 2008-01-19

The development of Punix is still hobbling along. It still needs a few things implemented before it can boot up completely; the three major components it needs are a memory allocator, a file system, and a Flash ROM block device driver. It already has most of the upper and middle layers of the file system written, but it lacks the low-level code to read and write an actual file system on a block device.

In the last month I've been adding a lot of support code for the file system, mostly taking code from UNIX V6 and V7 and re-writing it for Punix. I've been adding this and other low-level driver code (including a new and improved virtual terminal driver!) without testing each time. In fact, until last night it wouldn't completely link because it had some unresolved symbols.

A few nights ago I resolved the symbols (either by implementing the missing functions or by commenting out each reference to them) and linked it all together. Then I ran it in TiEmu to test it. I could step through it instruction-by-instruction, but at one point it tries to write to an illegal address and goes to the "address error" exception. At this point I discovered that the vector table containing the "address error" and other vectors is partially corrupted! See http://p094.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=3486.topic, starting at the third post. I tried moving symbols around, even inserting literal values in the vector table, but those incorrect values (which Lionel Debroux suggests may be a certificate field) still appear there in the TIB file, even before it's loaded onto the calculator.

Today I reduced the test program to one file. I found that if the vectors table contains a symbol reference (even to a symbol in the same file), the certificate field appears. However, if the values are all hard-coded, the certificate field does not appear. This probably means it's a bug, or at least an undocumented feature, in the TIGCC linker.

Last, I'd like to mention that someone has volunteered to help work on some of the missing components, so hopefully this means development will pick up pace.