On Wed, Apr 18, 2001 at 10:11:11PM +0200, Andreas Jaeger wrote:
> Daniel Jacobowitz <email@example.com> 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.
Yes, I think it does. Do we care about being able to build with old
(including every released version before [I think] HJ's 18.104.22.168.5)
binutils on MIPS? Having it both ways is pretty hard, but it could
probably be autoconfed.
> 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.
Well, this will need a comment from someone with a better understanding
of ELF than I, but my thought:
How harmful would it be, given that we've been assuming the hardcoded
base address of 0x5ffe0000, to assume that the base address is either
that or 0? Just check if subtracting 0x5ffe0000 from the base address
of the first load would be an obvious error (i.e. if it would
Could someone enlighten me on when the vaddr of the first load command
is not the same as MIPS_BASE_ADDRESS? I could easily enough (since
we've already seen the PT_DYNAMIC entry at this point) read the
BASE_ADDRESS value out of the library, but that's a bit of a speed hit.
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team