>  > ELFDEFNNAME(NO_ADDR) is defined as ELF64_NO_ADDR 
>  > ELF64_NO_ADDR is defined as (~(Elf64_Addr)0) 
>  > And this turns into (uint64_t)-1
> 
> The NetBSD/mips sources are in no position to be built as LP64.

Well, if I remove -Werror to get this problem corrected, I can build a
LP64 kernel. This kernel is able to boot, but because system calls are
completely broken, init dies quickly.

In fact there is a padding problem because sizeof(register_t) is not
equal to sizeof(mips_regs_t), hence when you write(2, 0x7fff40b0, 6),
the kernel understands write(0, 2, 0).

In fact I'm surprised it's even able to create the init process, I
really expected fatal pmap problems.

> To be honest, I'm slightly annoyed at how you've approached the whole
> N32/IRIX compat thing.  You seem to be looking for quick fixes.

To be honest I am. I'm now hang on o32 compatibility because of a
strange VM problem. I'd like to go foward with the system call
emulation, and n32 is an opportunity to do so. Hence I'd by happy to
have a LP64 kernel running just our current o32 userland and N32
binaries. Don't worry, I won't commit theses changes, I understood that
this is not The Right Way nor The Desired Way. 

> How about instead you gather up information on all the changes that need
> to happen to the MIPS code first, and start making the incremental changes
> necessary, rather than blindly trying to build an LP64 kernel, when we don't
> even have the toolchain support for it in the tree yet.

I don't need to be able to natively build N32 binaries in order to work
on IRIX n32 emulation... anyway, working on 64 bit support on the Mips
is an interesting project, and I'm okay to work on this too, so please
tell me where I can gather information about all the changes that need
to happen (I still have to buy 'see mips run')

-- 
Emmanuel Dreyfus
manu@netbsd.org