Date: Sat, 15 Sep 2001 16:03:53 -0600 From: "Addr.com Web Hosting" <support@addr.com> To: freebsd-ia64@FreeBSD.ORG Subject: Re: freebsd-ia64-digest V5 #26 Message-ID: <5.0.0.25.2.20010915160349.018f8d50@denver.den.addr.com> In-Reply-To: <bulk.42382.20010904020328@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.0.25.2.20010915160349.018f8d50>