n32 support patches

[C. Jayachandran]

On Tue, Mar 2, 2010 at 1:07 AM, Juli Mallett <jmallett at freebsd.org> wrote:
> On Mon, Mar 1, 2010 at 06:28, C. Jayachandran <c.jayachandran at 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.  I 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.  I
> 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 — the day is young) before moving on to fixing
> the problems with dynamic linking.  If 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 — 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.  Do 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.