Date: Wed, 21 Nov 2001 11:49:02 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@wemm.org> Cc: <ia64@FreeBSD.ORG> Subject: Re: Things to do Message-ID: <Pine.BSF.4.33.0111211131160.74474-100000@herring.nlsystems.com> In-Reply-To: <20011120195708.8C9333811@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Nov 2001, Peter Wemm wrote: > 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. It ought to be safe to free fptrs for functions in a module when that module is unloaded. If someone else still has a pointer to a function in the module being unloaded, then they are in trouble anyway even on arches which don't use funky pointers for functions. I think that the right approach is probably per-module fptr pools and when we resolve fptrs from a new module, they are allocated from whichever module which owns the function that we resolve to. In ld-elf.so, we keep a table per module which is indexed by symbol number to make it easy to keep the fptrs unique. Also, in ld-elf.so we don't resolve fptrs in the self-relocator but instead we fix them up in C code as part of the loader's bootstrap process. We could do something like this in the kernel too - just process REL64 relocations in the self-relocator and fix the rest from ia64_init(). We just need to make sure that we don't call anything which uses function pointers (e.g. printf) until we have finished the job. > > > > > 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). I've been trying to remember to change this for a while. We should not use f16-f31 in the kernel at all. They would be saved/restored correctly by the compiler for traps and exceptions but it isn't safe since context switches don't save/restore them. We only save/restore f2-f5 in context switches. We could probably get away with restricting the kernel to just the temporaries, i.e. f6-f15 - if gcc wants to preserve a value over a call, then it can still spill onto the stack. > > > > > 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. No, this is present in C0 errata. The problem is that if the low 32bits of ar.itc happen to be all ones at the time of the read, then the value read is wrong. We need to check for a low part of 0xffffffff and re-read. > > > > > 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. This would be quite tricky to do right. The current pmap is definately oriented towards a single page size. > > 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... The page size from the RR affects the VHPT hashing function. The actual PTE in the VHPT can override the page size though, allowing a larger page to be inserted into the TLB. Basically, you have to insert multiple copies of the large page PTE into each location of the VHPT that covers the large page. -- 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.0111211131160.74474-100000>