n32 support patches

[Juli Mallett]

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!

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?

Thanks,
Juli.