Daniel Jacobowitz <dan@debian.org> writes:
> 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
Do I understand you correctly that glibc needs a patch? Please send
it to me.
> 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?
You might be - but it's quite difficult to fix in glibc. If you get
it working in glibc, send me a patch that works with old and new
binaries - and I'll gladly review and commit it.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
