Date: Tue, 20 Nov 2001 11:57:08 -0800 From: Peter Wemm <peter@wemm.org> To: Doug Rabson <dfr@nlsystems.com> Cc: ia64@FreeBSD.ORG Subject: Re: Things to do Message-ID: <20011120195708.8C9333811@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.33.0111201058430.54216-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > On Mon, 19 Nov 2001, Peter Wemm wrote: > > > Doug Rabson wrote: > > > An updated random list of things which need doing: > > > DDB 'n' command > > > Remote GDB support > > > link_elf backend > > > > I'll take a shot at this unless somebody else wants to do it. We can't > > have those sparc64 guys having kld's before us and going unchallenged. :-) > > It should be pretty easy now that we have ld-elf.so working. We need to > recover the sym->fptr mapping information that the self-relocator > generates so that function pointer comparisons with kernel functions works > right in a loaded module. Aha! Thanks for the tip. I had not thought about the consequences of having different pointers to the same functions. I was planning to keep a seperate pool of fptr's per module and free them at unload time. Thinking a bit more about it, perhaps we should just incrementally increase the fptr pool and never free it? At worst we have one fptr per public entry point and keep reusing the old ones at the next load. Freeing them would require reference counting, but I guess that could be done. Actually, we'll need some sort of recovery system because we can have cross-module calls with fptrs pointing into modules.. these will be invalid after that module is unloaded. > > > FPSWA support > > > > Should be done. There is test code at: > > http://people.freebsd.org/~peter/fpswa/ > > There are four examples from the manual: > > "Itanium Processor Floating point Software Assistance and Floating > > Point Exception Handling" manual. The code is out of sync with reality > > though, the manual says two of the examples should cause a FP trap/fault, > > but in fact three of them do. (I cant change the fact that the hardware > > causes a trap on their code when the docs say the hardware doesn't. :-). > > I'm very slightly worried by the possibility that the compiler might take > it into its head to start saving/restoring some of the call-saved fp > registers between getting to trap() and handling the fpswa interrupt. Its > not likely to happen but in theory we could detect and cope with this > using the stack unwinder. Hmm. We block out f32-127 from gcc, and save f6-15 on trap. Perhaps we could just go overboard and telling it to never use f2-5 and f16-31 in the kernel as well? Remember, we call this for *every* floating point fault/trap, whether it be a SWA request or not (there is no way to tell if it's a SWA request except by calling fpswa and see if it returns an all-clear or not). > > > Workaround ar.itc errata BTW; is this for the B step only cpus? I saw lots of A-step and some B-step workarounds in the linux ia64 code when I took a peek a few months back. > > > Use AllocatePages in copy.c to make sure we don't step on EFI > > > Resize VHPT based on physical memory > > > ia32 emulation > > > > This one will be really interesting.. I was going to have a shot at it > > but then I remembered the 4K page issue. In theory we could probably > > just let getpagesize() return an 8K or 16K page size, but we have to do > > nasty things to executables, ie: make up to the last 4k (for 8k pages) or > > up to 12K (for 16k pages) of text segments writeable.. And possibly tweak > > ld-elf.so.1 to expect trouble mmapping two different things to the same > > logical page. > > The Linux guys just pretend that the ia32 process has a 4k page size and > they paper over the cracks in calls like mmap and sbrk by dubious copying > and zeroing of the partial pages. Seems to work though. Eww, nasty. I suspect they can get away with it because they have a VM system that runs at a much lower level and they can see the effects of this at page table level. What I thought about was a little more creative. I dont know if this is what you described before, but: - set region 0 to 4K page size - have pmap wire in each 8k or 16k (or whatever) page into 2 or 4 4K slots - when there is a mapping conflict, we can wire different parts of different VM pages into different 4K slots. However, this sends a shiver down my spine. Maybe it is just simply better to allow conflicting mmap's in copy-on-write mode to overlap for these processes. I've got some other wild ideas as well, but one question.. the page size is constant on a region (or RR specifically), right? Is there any opportunity to use different pages at once? (I do not remember this, but I dont expect so). If it is variable, then perhaps some sort of clustering mechanism for VM itself may be in order. That could help x86 for 4MB page support for devices, sysvshm, etc. Hmmm... > > > Write pipelined bcopy/memcpy > > > > I thought I saw some sample code from intel somewhere... > > That would be nice. I think I saw an SSE based one too. I'm not sure what the register footprint of this was though. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011120195708.8C9333811>