I've been trying to make this patch work as part of a complete toolchain, based on glibc. In addition to a little snag (when building glibc for big-endian mips you need an equivalent change in the target format), I hit a serious shared library error - nothing linked dynamically worked. This is the cause: --- elf32lsmip.sh Thu Jun 3 14:02:10 1999 +++ elf32ltsmip.sh Wed Apr 11 00:14:08 2001 ... -SHLIB_TEXT_START_ADDR=0x5ffe0000 +SHLIB_TEXT_START_ADDR=0x0 Is this necessary for the ABI? If so, glibc needs to be updated to reflect that: /* * MIPS libraries are usually linked to a non-zero base address. We * subtract the base address from the address where we map the object * to. This results in more efficient address space usage. * * FIXME: By the time when MAP_BASE_ADDR is called we don't have the * DYNAMIC section read. Until this is fixed make the assumption that * libraries have their base address at 0x5ffe0000. This needs to be * fixed before we can safely get rid of this MIPSism. */ #if 0 #define MAP_BASE_ADDR(l) ((l)->l_info[DT_MIPS(BASE_ADDRESS)] ? \ (l)->l_info[DT_MIPS(BASE_ADDRESS)]->d_un.d_ptr : 0) #else #define MAP_BASE_ADDR(l) 0x5ffe0000 #endif Of course, now that is completely wrong. One of the two definitely needs to give. From the evilness of the hack in glibc, I'm assuming that glibc needs to give. Am I on the right track here? -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team
