Sunday, August 23, 2009

mips64 multilib support

My current plan is to have the toolchain default to the N32 (IPL32 LL64) ABI for most programs but allow N64 programs to be built. The N64 libraries would not be required to live under a emulation but would be integrated with N32 libraries under /usr/lib.

But first is the ld.elf_so problem. If you are going to run O32 binaries, they will expect to execute ld.elf_so and find binaries in lib or /usr/lib. Now we could tweak ld.elf_so to prefer libraries in ${LIBDIR}/${abi} but should N32/N64 binaries use ld-${ABI}.elf_so to preserve use of O32 binaries? The kernel could also changed to change ld.elf_so to ld-${ABI}.elf_so and use that in preference. Got to ponder on this problem.

Let's say we have /usr/lib/libc.so and /usr/lib/n64/libc.so. Now for maximum performance, do you want to support ${LIBDIR}/${ABI}/${ARCH}/libc.so where the dynamic loader looks at the architecture embedded in the ELF flags and tries to find a library there first, then fall back to ${LIBDIR}/${ABI}? It seems to be a win in that you can have a system with tuned libraries for mips1, mips3, mips32, mips64 without having tied to that hardware.

mips32 is only use for O32 binaries any platform running N32 or N64 is going to have to be 64bit in nature.

No comments:

Post a Comment