[Top] [All Lists]

Re: Question on the binutils tradlittlemips patch

To: Keith M Wesolowski <>
Subject: Re: Question on the binutils tradlittlemips patch
From: Daniel Jacobowitz <>
Date: Sun, 22 Apr 2001 22:19:53 -0400
Cc: "Steven J. Hill" <>,
In-reply-to: <>; from on Sun, Apr 22, 2001 at 06:07:18PM -0700
References: <> <> <> <>
User-agent: Mutt/1.3.16i
On Sun, Apr 22, 2001 at 06:07:18PM -0700, Keith M Wesolowski wrote:
> On Wed, Apr 18, 2001 at 04:37:27PM -0400, Daniel Jacobowitz wrote:
> > If you're referring to libc-mips-04052001.patch.bz2, that's what I
> > started with.  I needed two changes on top of it.  I'll post them in a
> > bit.
> Have you or anyone else made further progress on this?  One of the
> additional patches is obvious; the glibc stuff is not so obvious.

I have them working in the case I care about - no backwards
compatibility at all.  We (Monta Vista) can get away with this :)
I've attached the patches.

I can not do a more general fix for supporting both kinds of
executables unless someone with a better understanding of ELF than I is
willing to answer the questions I believe I sent to this list a few
days ago.

The only way I can see to get at the DT_MIPS(BASE_ADDRESS) or whatever it
was called early enough to use it requires some extra disk activity; it
shouldn't be too harmful, but I'd rather not impose that much of a
speed penalty for every open of a shared object.  Perhaps it could be
done efficiently with mremap()...

I still don't see why BASE_ADDRESS is necessary, but I'm sure there was
a good reason it was added.  I've never seen a shared object with the
virtual address of the first LOAD not equal to the base address...

Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team

Attachment: glibc-mips-abi.patch
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>