Date: Sat, 24 May 2003 19:03:09 -0700 From: Peter Wemm <peter@wemm.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_int Makefile amd64.patch Message-ID: <20030525020309.B17C42A8B1@canning.wemm.org> In-Reply-To: <200305242058.h4OKwliu004071@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> Modified files:
> gnu/usr.bin/cc/cc_int Makefile
> Added files:
> gnu/usr.bin/cc/cc_int amd64.patch
> Log:
> Add a temporary indirect patch for gcc when targeting amd64. This is to
> give the cvs tree a surviving a 'make world'.
For what its worth, 'make TARGET_ARCH=amd64 buildworld' and buildkernel etc
produce a viable, bootable system.
The main things missing still:
- threads (get/setusercontext/swapcontext/makecontext etc and kse kernel bits)
- USER_LDT (however, there is a syscall to set the %fs and %gs base values
to arbitary 64 bit addresses).
- ACPI
- SMP
- kld module support (the elf_machdep.c relocator is wrong).
- finish the missing relocation types in rtld-elf/amd64/reloc.c (easy)
- boot blocks (need gcc -m32 to work)
- ppp(8) (compiler bug, hack in http://people.freebsd.org/~peter/hammer.diff,
but gcc-3.3 would be much better)
- performance tuning (segment registers etc at context switch time, pmap)
- 'make release'
- X server
- gdb
- ddb (needs a dwarf2 based unwinder to get stack traces and a disassembler)
- libstdc++.so (build bug, tries to link libgcc.a (non-pic) into the .so,
but the libstdc++.a works).
- crashdumps?
- teach libkvm about crashdumps.
- see if openssl can use the assembler x86-64 routines.
- 128TB of user process VM space
- full 2MB pmap page support in pmap
- SSE/SSE2 support in libc (the fpget/set*() functions need to adjust the
SSE MXCSR register as well as the x87 control word).
Notable things that are working:
- 512GB of user process VM space for 64 bit apps
- 4GB of user process VM for 32 bit apps (well, 4K short of 4GB)
- fast syscall/sysret/swapgs/etc
- 4 level page table support (needs optimizing and 2MB pages need to be fixed)
- uses a 'direct mapped' memory segment in the kernel to avoid temporary
mappings to get to page table pages.
- should support up to 512GB of physical memory
- i386 binary support, although it has quite a few missing bits. The p4
binaries work though. I do not expect it to run many system level
programs yet (the state of termios/ioctl consumers is unknown).
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030525020309.B17C42A8B1>