Date: Tue, 20 Nov 2001 11:05:20 +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.0111201058430.54216-100000@herring.nlsystems.com> In-Reply-To: <20011119201639.589F738FF@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > > 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. > > > Workaround ar.itc errata > > Figure out why loader.rc hangs the loader > > Almost certainly a trap/fault (divide by zero or something). I'll look > for this soon if nobody else spots it. I got as far as trying to run loader.rc with skiload and it was sending out some mighty bogus pathnames to open(). I got the impression that there might be a null-pointer problem somewhere. > > > 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. > > > Write pipelined bcopy/memcpy > > I thought I saw some sample code from intel somewhere... That would be nice. > > EPC-based syscalls instead of break syscalls > > Linux still uses break, right? Right. -- 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.0111201058430.54216-100000>