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
Is this necessary for the ABI? If so, glibc needs to be updated to
* 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.
#define MAP_BASE_ADDR(l) ((l)->l_info[DT_MIPS(BASE_ADDRESS)] ? \
(l)->l_info[DT_MIPS(BASE_ADDRESS)]->d_un.d_ptr : 0)
#define MAP_BASE_ADDR(l) 0x5ffe0000
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