[self-interest] Re: i386 Port: Status

[Gordon F. Cichon]

Dave Ungar wrote:
> Congrats on all the progress you have made!
> The trapdoor stuff was just an optimization for the PPC, which
> had limited branch spans.
> I would not use them on Intel, unless you can go within the zone
> much easier than you can get from the zone to an asm stub.

I put the sparc dummy trapdoors in already, and it seems to work
so far.

> As for the signal handler function, I'm not sure I understand
> what is in the VM vs. what your system is doing.

It is naming conventions most of the time. The Linux kernel 2.0
simply did not switch the stack, unless you put an alternate stack
pointer into sa_restorer (!) and you were running on root privileges.
The signal handler was a C function called with one argument, namely
the signal number. The saved registers were saved just behind (above?),
fortunately on the user stack, so that you could cast a pointer to
a structure which was defined in a (internal) kernel header file.
BTW, can anybody tell me what sa_restorer is good for originally?

With kernel 2.2 (and glibc 2.0) this is much cleaner:
The signal handler is called with three args:
void (*_sa_sigaction)(int, struct siginfo *, void *);
The third arg is actually a pointer to a 'struct ucontext' -
a struct that is not referenced by any header file in user space.
There is no ucontext_t as in Solaris, and the glibc docu says that
Linux implements BSD style signal stacks. I don't know the difference
between the different styles of signal stacks.

Also, the glibc docu says that the preferred way of switching
stacks was via longjmp. I can't find this right now in my header
files, but I remember some portable way of exposing pc and sp
in the longjmp buffer which I think pthreads used once to implement
multithreading. Since longjmp thread switching always have to take
place using a dummy function call, the register contents of the 
most recent activation could be reached by walking the stack from
the longjmp buffer canonically, and one would not have to deal with
yet another special structure for saving register contents (i.e.
the ucontext). Is anybody out there who an remember how the portable
longjmp multithreading worked? Are there any principal objections
against using this approach in the Self VM?

I am not yet sure which way to go (the ucontext or the longjmp way).
Do you have any other comments or suggestions?
 
> BTW: I have put in some time today getting Self to run on 24-bit SPARC
> frame buffers. Fixed two bugs, but more remain.

Great!
I am running a 16 bit frame buffer, BTW ;-)

Gordon.