Date: Tue, 2 Mar 2010 09:38:13 +0530 From: "C. Jayachandran" <c.jayachandran@gmail.com> To: Juli Mallett <jmallett@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: n32 support patches Message-ID: <98a59be81003012008y5b294094mc7139dd96836fa04@mail.gmail.com> In-Reply-To: <eaa228be1003011137y62980f9dl1fb389825c36aeef@mail.gmail.com> References: <98a59be81003010628g6099768erc397bc90841840f8@mail.gmail.com> <eaa228be1003011137y62980f9dl1fb389825c36aeef@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett <jmallett@freebsd.org> wrote: > On Mon, Mar 1, 2010 at 06:28, C. Jayachandran <c.jayachandran@gmail.com> = wrote: >> I'm in the process of getting n32 ABI support for the RMI processors. >> The plan is have n32 compiled kernel with 64-bit register_t and >> physaddr_t and 32 bit long and pointer types. > > Hi JC, > > I've been working on this too in my user/jmallett/octeon branch in > Subversion and have gotten past some of the problems you mention, but > not always in the cleanest of ways. =A0I switched to using the libgcc > softfloat implementation instead of the libc one, for example, and > have committed some changes from Warner to libc's abicalls support. =A0I > am currently running with a static root filesystem to track down some > bugs with syscalls (I think just the ones with lots of arguments, i.e. > the ones we need to do copyin to get; or maybe it's the bogus quad > stuff, I don't know yet =97 the day is young) before moving on to fixing > the problems with dynamic linking. =A0If there's any way to coordinate > our efforts and you'd like to, let me know! I was not aware of this, thanks for the update. I will have a look at this branch. > One thing I will say is that I've been talking with Warner and we > think that n32 kernels are probably a pretty bad idea =97 a lot of the > system depends on pointers being the same width as registers, etc. > Neither of us could really think of a case where you'd want an n32 > kernel instead of an n64 kernel except for the case where your > bootloader just can't handle ELF64, in which case a trampoline or an > n32/o32 loader which can load ELF64 seems more beneficial. =A0Do you > have a use case in mind, or is it just that n32 is an easier target > than n64? (I saw similar comments from Warner and Randall too, but I will reply here) My own final target is to have n64 support for XLR - I see n32 is just a first useful step in that direction. But I think the easiest way is to go n32 -> n32+64bit phys -> n64. The first step n32 will work out the ABI issues as it is very similar to n64. A lot of the initial kernel changes (for 64 bit registers, ABI support for system calls and signal handling) and user-space (ABI support for system call/ld.so etc) can be worked out here. n32+64bit phys will hopefully work out the next level of issues(TLB/page table entries). From there n64 will be getting the 64bit pmap and working out 64-bit compilation. Also I think it will be useful to have an advanced 32 bit option for mips64 and better architectures. o32 is inefficient in processors supporting mips64 instruction set (64 bit operations are split instead of using 64 bit operations). And some customers we talked to have large amounts of probably-not-64-bit-clean source code, so a 32 bit option is always useful. On the 64-bit registers and 32-bit pointers issues - RMI's initial port was o64 and 64 bit physical addres We did not have many issues in the main kernel. The intel PAE mode, which seems to be supported has a similar setup (32bit with 64bit physical addr) was already supported in kernel, so our effort was minimal here. So overall, I think of n32 as a useful thing, and I don't think there will be any additional code just for n32 because it should be a subset of n64 support. Regards, JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98a59be81003012008y5b294094mc7139dd96836fa04>