[Openmcl-devel] Solaris x86-64 progress

[Gary Byers]

One thing that you can try (it won't really get very far, but ...)
is to rename a Linux or Darwin heap image to whatever the Solaris
kernel expects, and see if you can map it into memory and start
executing code.  (Try setting a breakpoint at _SPfuncall; if you
get there and single-step for a few instructions, you should
find yourself executing compiled lisp code if everything got
mapped in right.)  One of the first things that'll happen is
that MAKE-READ-WRITE-LOCK will cons, and that'll give you
the opportunity to debug the exception handler (I'm sure that
you're looking forward to that ...)  Before too long, the
Linux/Darwin image will probably try to do something Linux-
or Darwin-specific, but there's likely stuff to exercise before
it gets to that point.

As far as syscall interfaces go: there's already some variance
between supported OSes, reflected by conditionalizaion in
(especially) l1-sockets.lisp and linux-files (which is misnamed:
the use of "linux" in the filename should be read "as opposed
to the old classic MacOS filesystem stuff from Way Back When.")

Some of the use of direct system calls (rather than just going
through a C wrapper and maybe checking errno) is historical:
in the days of cooperatively-scheduled threads, errno was
a shared global and it was easy to forget to do whatever
needed to be done to ensure that errno was set and tested
atomically (and therefore easy to test the result of
a direct system call, which would usually be negative if
an error occurred.)  For most of the stuff in l1-sockets
and linux-files, it'd be fine to just do an ff-call and
a call to (ccl::%get-errno) afterward, if necessary.
(CCL::%GET-ERRNO returns the negated thread-local errno
and ses the thread-local variable to 0; Matt recently
found a bug where it was actually setting it to whatever
was in the f0 (xmm0) register.)

Some of the syscalls in level-0 may -need- to be syscalls,
since they may need to run before the FFI is fully initialized.
(Even that may be less true than it once was; I'm not sure.)



On Fri, 18 Jan 2008, Chris Curtis wrote:

> I now have a kernel that successfully compiles, starts up and dies as 
> expected trying to load the as-yet-nonexistent heap image. There wasn't too 
> much I had to do that wasn't already at least sketched out. (M4 is still a 
> royal pain, in case anyone wondered.)
>
> At the moment I'm sorting through the syscalls, which are enormously tedious, 
> and also somewhat more complex than anticipated. There are two main issues:
>
> - Solaris sockets are just plain different. (For example, socket() isn't a 
> syscall.) There's a lot of work to dig through the APIs on both sides to make 
> sure everything lines up correctly, but I expect it to be relatively 
> straightforward.
>
> - Solaris has a bunch of subcoded syscalls. For example, setpgid is actually 
> done by calling syscall(SYS_pgrpsys, 4, pgid). This one is a little more 
> complicated and I'm not quite sure what the Right Thing To Do is.
>
> --chris
>
>
>
>