Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Sep 2001 11:35:02 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Peter Wemm <peter@wemm.org>
Cc:        <ia64@FreeBSD.ORG>, <jhb@FreeBSD.ORG>, <dfr@FreeBSD.ORG>
Subject:   Re: ia64 + kse == not happy.. 
Message-ID:  <Pine.BSF.4.33.0109031127410.30587-100000@herring.nlsystems.com>
In-Reply-To: <20010903084053.9E998380A@overcee.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Sep 2001, Peter Wemm wrote:

> I finally solved it.  I did a s/proc0/thread0/ in locore.s, forgetting that
> proc0 is a structure, and thread0 is a pointer that requires indirection.
>
> Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()?

Each register has an associated bit which determines whether it contains a
valid value. These "not a thing" bits are accumulated into the ar.rnat
register as registers are written to the register stack. After stacking 63
registers, the accumulated NaT bits are written to the stack. This happens
when the ar.bspstore pointer rolls past xxxxx1f8. To correctly fork a
child process, we must initialise its register stack and ar.rnat value so
that it contains reasonable values when its resumed. The correct ar.rnat
value is either the current process' ar.rnat if it has not yet been
flushed out since we entered the kernel or the value stored at rnatloc
otherwise. We determine this by checking to see if the current process'
ar.bspstore has gone past rnatloc.

>
> Anyway, ia64 + kse is happy so far.

:-)

>
> Some things I have noticed are missing:
> setjmp/longjmp() (these look non-trivial given the register stack :-(  )
> lots and lots and lots of minor things. :-)

I started working on this as part of an effort to get ficl working in the
EFI based loader. I got a bit stuck though - I probably should set up a
testcase that I can run under ski.

>
> I have been considering taking a shot at porting loader(8) to run under
> ski, and have *it* load the kernel via reading via sscdisk style
> operations..  This should enable us to have better control of our
> boot environment, symbol tables, etc.  I think. :-]

Ooh. I want one.

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
					Phone: +44 20 8348 6160



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ia64" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0109031127410.30587-100000>