[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-ia64
Subject: Re: freebsd-ia64-digest V5 #26
From: "Addr.com Web Hosting" <support () addr ! com>
Date: 2001-09-15 22:03:53
[Download RAW message or body]
At 02:03 AM 9/4/2001 -0700, you wrote:
>freebsd-ia64-digest Tuesday, September 4 2001 Volume 05 : Number 026
>
>
>
>In this issue:
>Re: ia64 + kse == not happy..
>Roadmap?
>Re: ia64 + kse == not happy..
>Re: ia64 + kse == not^H^H^Hnow happy..
>Re: ia64 + kse == not^H^H^Hnow happy..
>Re: Roadmap?
>Re: ia64 + kse == not happy..
>Re: Roadmap?
>Re: Roadmap?
>Re: Roadmap?
>Re: ia64 + kse == not^H^H^Hnow happy..
>Re: ia64 + kse == not^H^H^Hnow happy..
>Re: ia64 + kse == not happy..
>Re: ia64 + kse == not happy..
>Re: ia64 + kse == not happy..
>Re: ia64 + kse == not happy..
>
>----------------------------------------------------------------------
>
>Date: Mon, 03 Sep 2001 01:40:53 -0700
>From: Peter Wemm <peter@wemm.org>
>Subject: Re: ia64 + kse == not happy..
>
>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()?
>
>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 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. :-]
>
>Peter Wemm wrote:
> > After doing an alpha-style conversion of the ia64 code in the kse
> > tree to get it to build/run, I have run into a brick wall. :-(
> >
> > loading kernel.kse...
> > starting kernel...
> > Memory descriptor count: 1
> > MD 0: type 7 pa 0x200000 cnt 0x4000
> > Descriptor 0 contains kernel
> > Loading chunk before kernel: 0x200 / 0x500
> > Loading chunk after kernel: 0x819 / 0x4200
> > step 1:
> > proc0uarea = 0xe000000000200000
> > proc0kstack = 0xe000000000201000
> > td_pcb = 0xe000000000204920
> > td_frame = 0xe0000000002046d0
> > pcb_sp = 0xe0000000002046c0
> > pcb_bspstore = 0xe000000000201000
> > made it to the end of ia64_init
> > Copyright (c) 1992-2001 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> > FreeBSD 5.0-CURRENT #4: Sun Sep 2 07:28:56 PDT 2001
> > peter@overcee.netplex.com.au:/home/peter/fbp4/kse/sys/ia64/compile/SIM
> > real memory = 67108864 (65536K bytes)
> > Physical memory chunk(s):
> > 0x00209000 - 0x004fffff, 3108864 bytes (759 pages)
> > 0x00819000 - 0x041f7fff, 60682240 bytes (14815 pages)
> > avail memory = 60399616 (58984K bytes)
> > made it to the end of cpu_startup
> > linker_preload: in
> > linker_preload: out
> > mem: <memory & I/O>
> > Calibrating clock(s) ... failed, using firmware default of 0 Hz
> >
> > fatal kernel trap:
> >
> > trap vector = 0x18 (General Exception)
> > cr.iip = 0x0
> > cr.ipsr = 0x0
> > cr.isr = 0x0
> > cr.ifa = 0x0
> > cr.iim = 0x0
> > curthread = 0xe000000000815c20
> > pid = 0, comm = swapper
> >
> > Stopped at
> > db> 20000e
> > ?
> >
> > The actual change is at:
> > http://people.freebsd.org/~peter/p4db/chv.cgi?CH=1344
> >
> > And you can see any other changes at:
> > http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/kse/...
> >
> http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/kse/sys/i
> a64/...
> >
> > And, as announced elsewhere, the source can be had either from p4 if you
> > have a freefall account, or from cvsup10.freebsd.org
> (collection=p4-cvs-all,
> > release=cvs).
> >
> > Key questions and changes:
> >
> > Under KSE, the U area is split into two entities. One contains struct
> user,
> > and the other contains the kernel stack + pcb. We have been putting
> > the pcb at the *top* of the kernel stack on alpha / i386 since we have
> > a grow-down stack and we slip in a guard page underneath it. I did this
> > on the ia64 as well, but I think it may be a mistake as it looks like the
> > grow-up and grow-down stacks will collide before then and cause a
> bigger mess
> .
> > This can be easily backed out for testing, I'll try that soon.
> >
> > The old code did some odd things like subtracting 16 from the trapframe
> > for various stack pointers. I'm not quite sure what is going on here
> > but I tried to preserve it. I'd appreciate it if somebody could look over
> > the changes to machdep.c / vm_machdep.c etc in this area.
> >
> > I would really appreciate it if somebody could look over my *.s changes.
> >
> > Any ideas? I'm falling asleep. :-)
> >
> > Cheers,
> > -Peter
> > --
> > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
> > "All of this is for nothing if we don't go to the stars" - JMS/B5
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-ia64" in the body of the message
> >
> >
>
>Cheers,
>- -Peter
>- --
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 02:15:05 -0700
>From: Marcel Moolenaar <marcel@xcllnt.net>
>Subject: Roadmap?
>
>Guys,
>
>HP has given me an old (A1 stepping) Itanium box to play with. I don't
>know for how long, so I want to make the best use of it. Can someone
>tell me where we are on ia64?
>
>Also, what's the story with gcc. It doesn't look like we have a working
>ia64 compiler in the tree. Any ETA's on that front?
>
>I'll talk to the sysadmin next week, for I don't even know where the
>box is. After that I'll play with it to figure out what I can do and
>how best to do it. Any suggestions are welcome,
>
>- --
> Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 11:35:02 +0100 (BST)
>From: Doug Rabson <dfr@nlsystems.com>
>Subject: Re: ia64 + kse == not happy..
>
>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
>
>------------------------------
>
>Date: Mon, 03 Sep 2001 03:58:38 -0700
>From: Peter Wemm <peter@wemm.org>
>Subject: Re: ia64 + kse == not^H^H^Hnow happy..
>
>Doug Rabson wrote:
> > 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.
>
>Aha! that make some sense. I'm starting to understand the ia64 manuals
>now too.
>
>Question.. |= 1f8 depends on the stack starting at a xxxx000 address, right?
>The original committed ia64+kse stuff that worked had the pcb
>at the base of the stack, which meant that the bspstore started at some
>address like xxxx680. That |= 1f8 isn't space for a full 63 registers.
>Is it the address that is magic or the offset? Should it have been
>+= 1f8 instead of |= ?
>
>In any case it shouldn't matter now since the bspstore starts at a xxx000
>address now in the kse kernel (the pcb is at the top-of-stack, above
>trapframe and sp.)
>
>Speaking of sp, I've left some XXX comments about the -16 and +16 stuff...
>What is going on there?
>
> td2->td_pcb->pcb_sp = (u_int64_t)p2tf - 16;
>
>Is that just to arrange stack alignment on 16 byte boundaries? ie: like
>how we subtract sizeof(void *) in the i386 case but instead of 4 bytes
>it is 16?
>
> > > 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.
>
>Out of curiosity, what kind of lengths will setjmp/longjmp need to go
>to? I'm suprised ddb hasn't exploded because of this..
>
>If I had to guess, I would expect it to look a bit like the code in the
>tail end of cpu_fork().. ie: copy base registers, turn off rse, flush
>to backing store, turn rse back on?
>
> > > 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.
>
>Heh. dont we all. :-)
>
>Seriously, I think loader-under-ski is a good intermediate step before
>loader-under-efi, unless the efi case is already close to working. Even
>without ficl would be useful since we could have a real boot environment.
>
>Now to get the magic wand over to David O'Brien to get the gcc3 stuff with
>basic ia64 support in it. :-)
>
>Cheers,
>- -Peter
>- --
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 13:00:02 +0100 (BST)
>From: Doug Rabson <dfr@nlsystems.com>
>Subject: Re: ia64 + kse == not^H^H^Hnow happy..
>
>On Mon, 3 Sep 2001, Peter Wemm wrote:
>
> > Doug Rabson wrote:
> > > 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.
> >
> > Aha! that make some sense. I'm starting to understand the ia64 manuals
> > now too.
> >
> > Question.. |= 1f8 depends on the stack starting at a xxxx000 address,
> right?
> > The original committed ia64+kse stuff that worked had the pcb
> > at the base of the stack, which meant that the bspstore started at some
> > address like xxxx680. That |= 1f8 isn't space for a full 63 registers.
> > Is it the address that is magic or the offset? Should it have been
> > += 1f8 instead of |= ?
>
>Its the address thats magic. It doesn't matter where the stack started,
>ar.rnat is always spilled at addresses ending in 0x1f8.
>
> >
> > In any case it shouldn't matter now since the bspstore starts at a xxx000
> > address now in the kse kernel (the pcb is at the top-of-stack, above
> > trapframe and sp.)
> >
> > Speaking of sp, I've left some XXX comments about the -16 and +16 stuff...
> > What is going on there?
> >
> > td2->td_pcb->pcb_sp = (u_int64_t)p2tf - 16;
> >
> > Is that just to arrange stack alignment on 16 byte boundaries? ie: like
> > how we subtract sizeof(void *) in the i386 case but instead of 4 bytes
> > it is 16?
>
>The calling convention assumes that sp points at 16 bytes of scratch space
>on function entry. The +/- 16s are there to ensure this.
>
> >
> > > > 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.
> >
> > Out of curiosity, what kind of lengths will setjmp/longjmp need to go
> > to? I'm suprised ddb hasn't exploded because of this..
> >
> > If I had to guess, I would expect it to look a bit like the code in the
> > tail end of cpu_fork().. ie: copy base registers, turn off rse, flush
> > to backing store, turn rse back on?
>
>Its more similar to the code in cpu_switch() with some optimisations
>assuming that we only ever longjmp to somewhere which is further up our
>own stack.
>
> >
> > > > 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.
> >
> > Heh. dont we all. :-)
> >
> > Seriously, I think loader-under-ski is a good intermediate step before
> > loader-under-efi, unless the efi case is already close to working. Even
> > without ficl would be useful since we could have a real boot environment.
>
>The loader-under-efi case works well enough without ficl to get to the ok
>prompt. Some stubs need to be filled in to get the elf loader going and I
>need to write the magic trampoline code which turns on virtual addressing
>and bounces into the kernel.
>
> >
> > Now to get the magic wand over to David O'Brien to get the gcc3 stuff with
> > basic ia64 support in it. :-)
>
>Hmm. 3.0.1 doesn't compile KDE2 AFAIK.
>
>- --
>Doug Rabson Mail: dfr@nlsystems.com
> Phone: +44 20 8348 6160
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 14:05:51 +0100 (BST)
>From: Doug Rabson <dfr@nlsystems.com>
>Subject: Re: Roadmap?
>
>On Mon, 3 Sep 2001, Marcel Moolenaar wrote:
>
> > Guys,
> >
> > HP has given me an old (A1 stepping) Itanium box to play with. I don't
> > know for how long, so I want to make the best use of it. Can someone
> > tell me where we are on ia64?
> >
> > Also, what's the story with gcc. It doesn't look like we have a working
> > ia64 compiler in the tree. Any ETA's on that front?
> >
> > I'll talk to the sysadmin next week, for I don't even know where the
> > box is. After that I'll play with it to figure out what I can do and
> > how best to do it. Any suggestions are welcome,
>
>I strongly suggest that you try upgrading to something more recent (B3 or
>C0). A1 is old and buggy and I would prefer not to have to support it.
>Linux has recently de-supported anything older than B3.
>
>Compiler wise, gcc 3.0.1 sounds promising apart from the fact that it
>doesn't compile KDE2, which makes it unlikely to be imported any time
>soon.
>
>- --
>Doug Rabson Mail: dfr@nlsystems.com
> Phone: +44 20 8348 6160
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 14:58:02 +0100 (BST)
>From: Doug Rabson <dfr@nlsystems.com>
>Subject: Re: ia64 + kse == not happy..
>
>On Mon, 3 Sep 2001, Doug Rabson wrote:
>
> > 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 managed to find my problem with longjmp - it was a result of wrongly
>working around a difference between Intel's assembler and GAS. Hopefully,
>this should get me a bit further with the EFI loader and will be suitable
>for a libc setjmp/longjmp implementation.
>
>- --
>Doug Rabson Mail: dfr@nlsystems.com
> Phone: +44 20 8348 6160
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 09:15:31 -0500
>From: Brent Casavant <bcasavan@sgi.com>
>Subject: Re: Roadmap?
>
>On Mon, 3 Sep 2001, Marcel Moolenaar wrote:
>
> > HP has given me an old (A1 stepping) Itanium box to play with. I don't
> > know for how long, so I want to make the best use of it. Can someone
> > tell me where we are on ia64?
>
>Marcel,
>
>You should also know that late last year these boxes (I imagine you
>have what is known as "Big Sur", up to a 2P system) had a significant
>upgrade that replaced pretty much everything except the case, power
>supply, and fans. Oh, and the video card. That means that if you
>manage to get ahold of B3 or C0 processors they may or may not
>work correctly with the older motherboard/etc. Someone else may have
>experience in this area and be able to confirm whether newer
>processors will work.
>
>Brent
>
>- --
>Brent Casavant http://www.scc.net/~bcasavan
>b.j.casavant@ieee.org -.- -.. ..... . -- -...
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 10:10:26 -0700
>From: Marcel Moolenaar <marcel@xcllnt.net>
>Subject: Re: Roadmap?
>
>On Mon, Sep 03, 2001 at 02:05:51PM +0100, Doug Rabson wrote:
> > On Mon, 3 Sep 2001, Marcel Moolenaar wrote:
> >
> > I strongly suggest that you try upgrading to something more recent (B3 or
> > C0). A1 is old and buggy and I would prefer not to have to support it.
> > Linux has recently de-supported anything older than B3.
>
>No deal here. HP has explicitly stated that a processor upgrade is
>out of the question. The fact that I happen to have an A1 doesn't
>mean we need to support it. If FreeBSD is itself stable enough, I
>can more easily hijack one of the newer machines we have in use by
>using a diskless configuration.
>
>- --
> Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
>
>------------------------------
>
>Date: Mon, 3 Sep 2001 10:14:49 -0700
>From: Marcel Moolenaar <marcel@xcllnt.net>
>Subject: Re: Roadmap?
>
>On Mon, Sep 03, 2001 at 09:15:31AM -0500, Brent Casavant wrote:
> >
> > You should also know that late last year these boxes (I imagine you
> > have what is known as "Big Sur", up to a 2P system) had a significant
>[snip]
>
>I don't think it's a Big Sur. I believe it's a Lion box. But let me
>talk to the sysadmin first.
>
>- --
> Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
>
>------------------------------
>
>Date: Mon, 03 Sep 2001 20:44:55 -0700 (PDT)
>From: John Baldwin <jhb@FreeBSD.org>
>Subject: Re: ia64 + kse == not^H^H^Hnow happy..
>
>On 03-Sep-01 Doug Rabson wrote:
> > On Mon, 3 Sep 2001, Peter Wemm wrote:
> >> Now to get the magic wand over to David O'Brien to get the gcc3 stuff with
> >> basic ia64 support in it. :-)
> >
> > Hmm. 3.0.1 doesn't compile KDE2 AFAIK.
>
>Or kernels for that matter. It does evil things like convert 'printf("blah")'
>to 'puts("blah")' which doesn't work well for a kernel environment that
>doesn't
>have puts() or putchar(). :-/
>
>- --
>
>John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
>PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
>"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
>------------------------------
>
>Date: Mon, 03 Sep 2001 21:22:21 -0700
>From: Peter Wemm <peter@wemm.org>
>Subject: Re: ia64 + kse == not^H^H^Hnow happy..
>
>John Baldwin wrote:
> >
> > On 03-Sep-01 Doug Rabson wrote:
> > > On Mon, 3 Sep 2001, Peter Wemm wrote:
> > >> Now to get the magic wand over to David O'Brien to get the gcc3
> stuff with
> > >> basic ia64 support in it. :-)
> > >
> > > Hmm. 3.0.1 doesn't compile KDE2 AFAIK.
> >
> > Or kernels for that matter. It does evil things like convert
> 'printf("blah")
> '
> > to 'puts("blah")' which doesn't work well for a kernel environment that
> doesn
> 't
> > have puts() or putchar(). :-/
>
>This is easily fixed. :-)
>
>Cheers,
>- -Peter
>- --
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>------------------------------
>
>Date: Mon, 03 Sep 2001 21:23:22 -0700
>From: Peter Wemm <peter@wemm.org>
>Subject: Re: ia64 + kse == not happy..
>
>Doug Rabson wrote:
> > On Mon, 3 Sep 2001, Doug Rabson wrote:
> >
> > > 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 managed to find my problem with longjmp - it was a result of wrongly
> > working around a difference between Intel's assembler and GAS. Hopefully,
> > this should get me a bit further with the EFI loader and will be suitable
> > for a libc setjmp/longjmp implementation.
>
>Do you have something that you could check in in some form? Even if it
>doesn't work yet, just having *something* would be nice.
>
>Cheers,
>- -Peter
>- --
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>------------------------------
>
>Date: Tue, 4 Sep 2001 08:20:46 +0100 (BST)
>From: Doug Rabson <dfr@nlsystems.com>
>Subject: Re: ia64 + kse == not happy..
>
>On Mon, 3 Sep 2001, Peter Wemm wrote:
>
> > Doug Rabson wrote:
> > > On Mon, 3 Sep 2001, Doug Rabson wrote:
> > >
> > > > 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 managed to find my problem with longjmp - it was a result of wrongly
> > > working around a difference between Intel's assembler and GAS. Hopefully,
> > > this should get me a bit further with the EFI loader and will be suitable
> > > for a libc setjmp/longjmp implementation.
> >
> > Do you have something that you could check in in some form? Even if it
> > doesn't work yet, just having *something* would be nice.
>
>I chedked it in yesterday. I'm planning to play with loader a bit this
>morning - if that works now, I'll check what I have there in too.
>
>- --
>Doug Rabson Mail: dfr@nlsystems.com
> Phone: +44 20 8348 6160
>
>------------------------------
>
>Date: Tue, 04 Sep 2001 00:31:29 -0700
>From: Peter Wemm <peter@wemm.org>
>Subject: Re: ia64 + kse == not happy..
>
>Doug Rabson wrote:
> > On Mon, 3 Sep 2001, Peter Wemm wrote:
> >
> > > Doug Rabson wrote:
> > > > On Mon, 3 Sep 2001, Doug Rabson wrote:
> > > >
> > > > > I started working on this as part of an effort to get ficl
> working in t
> he
> > > > > EFI based loader. I got a bit stuck though - I probably should
> set up a
> > > > > testcase that I can run under ski.
> > > >
> > > > I managed to find my problem with longjmp - it was a result of wrongly
> > > > working around a difference between Intel's assembler and GAS.
> Hopefully,
> > > > this should get me a bit further with the EFI loader and will be
> suitable
> > > > for a libc setjmp/longjmp implementation.
> > >
> > > Do you have something that you could check in in some form? Even if it
> > > doesn't work yet, just having *something* would be nice.
> >
> > I chedked it in yesterday. I'm planning to play with loader a bit this
> > morning - if that works now, I'll check what I have there in too.
>
>Even if it doesn't, it would be nice if you could check it in.. That would
>save a lot of duplicated work for getting a ski-based hack to run. (I dont
>have real hardware yet).
>
>Cheers,
>- -Peter
>- --
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>------------------------------
>
>Date: Tue, 4 Sep 2001 10:01:48 +0100 (BST)
>From: Doug Rabson <dfr@nlsystems.com>
>Subject: Re: ia64 + kse == not happy..
>
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to mime@docserver.cac.washington.edu for more info.
>
>- --0-1211071170-999594108=:9620
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>On Tue, 4 Sep 2001, Peter Wemm wrote:
>
> > Doug Rabson wrote:
> > > On Mon, 3 Sep 2001, Peter Wemm wrote:
> > >
> > > > Doug Rabson wrote:
> > > > > On Mon, 3 Sep 2001, Doug Rabson wrote:
> > > > >
> > > > > > I started working on this as part of an effort to get ficl
> working in t
> > he
> > > > > > EFI based loader. I got a bit stuck though - I probably should
> set up a
> > > > > > testcase that I can run under ski.
> > > > >
> > > > > I managed to find my problem with longjmp - it was a result of
> wrongly
> > > > > working around a difference between Intel's assembler and GAS.
> Hopefully,
> > > > > this should get me a bit further with the EFI loader and will be
> suitable
> > > > > for a libc setjmp/longjmp implementation.
> > > >
> > > > Do you have something that you could check in in some form? Even if it
> > > > doesn't work yet, just having *something* would be nice.
> > >
> > > I chedked it in yesterday. I'm planning to play with loader a bit this
> > > morning - if that works now, I'll check what I have there in too.
> >
> > Even if it doesn't, it would be nice if you could check it in.. That would
> > save a lot of duplicated work for getting a ski-based hack to run. (I dont
> > have real hardware yet).
>
>Ok, apart from this ficl patch which I sent to you and dcs, I'm done. I
>have a loader which 'works' both with and without ficl. You will need to
>freshen your copy of libstand.a - I suggest using the handy attached
>ia64-make script for this purpose.
>
>Index: words.c
>===================================================================
>RCS file: /home/ncvs/src/sys/boot/ficl/words.c,v
>retrieving revision 1.35
>diff -u -r1.35 words.c
>- --- words.c 2001/05/27 16:30:10 1.35
>+++ words.c 2001/09/04 08:26:02
>@@ -1147,7 +1147,7 @@
> static void elseCoIm(FICL_VM *pVM)
> {
> CELL *patchAddr;
>- - int offset;
>+ FICL_INT offset;
> FICL_DICT *dp = ficlGetDict();
>
> assert(pBranchParen);
>
>- --
>Doug Rabson Mail: dfr@nlsystems.com
> Phone: +44 20 8348 6160
>
>
>- --0-1211071170-999594108=:9620
>Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ia64-make
>Content-Transfer-Encoding: BASE64
>Content-ID: <20010904100148.M9620@salmon.nlsystems.com>
>Content-Description:
>Content-Disposition: attachment; filename=ia64-make
>
>ZXhwb3J0IENDPSdpYTY0LXVua25vd24tbGludXgtZ2NjIC1PIC1EX19GcmVl
>QlNEX18gLVVfX2xpbnV4X18nDQpleHBvcnQgTEQ9aWE2NC11bmtub3duLWxp
>bnV4LWxkDQpleHBvcnQgTk09aWE2NC11bmtub3duLWxpbnV4LW5tDQpleHBv
>cnQgUkFOTElCPWlhNjQtdW5rbm93bi1saW51eC1yYW5saWINCmV4cG9ydCBP
>QkpEVU1QPWlhNjQtdW5rbm93bi1saW51eC1vYmpkdW1wDQpleHBvcnQgT0JK
>Q09QWT1pYTY0LXVua25vd24tbGludXgtb2JqY29weQ0KZXhwb3J0IE1BQ0hJ
>TkVfQVJDSD1pYTY0DQptYWtlICRADQo=
>- --0-1211071170-999594108=:9620--
>
>------------------------------
>
>End of freebsd-ia64-digest V5 #26
>*********************************
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with unsubscribe freebsd-ia64-digest in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ia64" in the body of the message
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic