Subject: Question on the binutils tradlittlemips patch

From: Daniel Jacobowitz <[email-masked]>
Date: Wed, 18 Apr 2001 14:19:59 -0400

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

---

From: Andreas Jaeger <[email-masked]>
Date: 18 Apr 2001 22:11:11 +0200

> 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.

> 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 [email-masked]
   private [email-masked]
    http://www.suse.de/~aj

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 18 Apr 2001 15:47:38 -0500

> dynamically worked.  This is the cause:
Yes, I have a patch against GLIBC. Go to my FTP site here:

    ftp://ftp.cotw.com/pub/linux/nino/toolchain

It is currently a hack as I have not figured out how to construct a
patch for GLIBC since it will break the other MIPS targets. See if
it helps.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

---

From: Daniel Jacobowitz <[email-masked]>
Date: Wed, 18 Apr 2001 16:37:27 -0400

> patch for GLIBC since it will break the other MIPS targets. See if

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.

---

From: Daniel Jacobowitz <[email-masked]>
Date: Wed, 18 Apr 2001 17:03:58 -0400

> Do I understand you correctly that glibc needs a patch?  Please send

Yes, I think it does.  Do we care about being able to build with old
(including every released version before [I think] HJ's 2.10.91.0.5)
binutils on MIPS?  Having it both ways is pretty hard, but it could
probably be autoconfed.

> 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
overflow).

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.

---

From: Keith M Wesolowski <[email-masked]>
Date: Sun, 22 Apr 2001 18:07:18 -0700

> started with.  I needed two changes on top of it.  I'll post them in a

Have you or anyone else made further progress on this?  One of the
additional patches is obvious; the glibc stuff is not so obvious.

-- 
Keith M Wesolowski <[email-masked]> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"Nothing motivates a man more than to see his boss put
	 in an honest day's work." -- The fortune file

---

From: Daniel Jacobowitz <[email-masked]>
Date: Sun, 22 Apr 2001 22:19:53 -0400

> 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
diff -urN libc-04052001/sysdeps/mips/mipsel/rtld-parms libc-04052001-patched/sysdeps/mips/mipsel/rtld-parms
--- libc-04052001/sysdeps/mips/mipsel/rtld-parms	Sat Jul 12 18:26:15 1997
+++ libc-04052001-patched/sysdeps/mips/mipsel/rtld-parms	Fri Apr  6 09:23:27 2001
@@ -1,3 +1,3 @@
 ifndef rtld-oformat
-rtld-oformat = elf32-littlemips
+rtld-oformat = elf32-tradlittlemips
 endif
--- glibc-2.2.3/sysdeps/mips/rtld-parms.orig	Wed Apr 11 16:12:56 2001
+++ glibc-2.2.3/sysdeps/mips/rtld-parms	Wed Apr 11 16:13:03 2001
@@ -2,7 +2,7 @@
 rtld-wordsize = 32
 endif
 ifndef rtld-oformat
-rtld-oformat = elf$(rtld-wordsize)-bigmips
+rtld-oformat = elf$(rtld-wordsize)-tradbigmips
 endif
 ifndef rtld-arch
 rtld-arch = mips
--- glibc-2.2.3/sysdeps/mips/dl-machine.h.orig	Wed Apr 18 14:20:17 2001
+++ glibc-2.2.3/sysdeps/mips/dl-machine.h	Wed Apr 18 14:21:15 2001
@@ -61,6 +61,9 @@
    in l_info array.  */
 #define DT_MIPS(x) (DT_MIPS_##x - DT_LOPROC + DT_NUM)
 
+#if 0
+/* mvista: This is no longer needed, or safe, after the tradlittlemips patch. */
+
 /*
@@ -76,6 +79,7 @@
+#endif
 #endif
 
 /* If there is a DT_MIPS_RLD_MAP entry in the dynamic section, fill it in

---

From: Keith M Wesolowski <[email-masked]>
Date: Sun, 22 Apr 2001 21:23:01 -0700

> I've attached the patches.

This looks like what I have come up with as well.  I don't care about
backward compatibility either.  If someone else wants to support
broken crap that's their problem; in an age where we have scripts and
makefiles to rebuild entire systems from source I can't see the point
of binary compatibility.

---

From: Daniel Jacobowitz <[email-masked]>
Date: Mon, 23 Apr 2001 00:34:40 -0400

> makefiles to rebuild entire systems from source I can't see the point

Don't you wish?  My other hat is Debian, which can't just ditch
existing MIPS installations like that.

---

From: Andreas Jaeger <[email-masked]>
Date: 23 Apr 2001 07:54:47 +0200

> existing MIPS installations like that.

And that's the problem I have with glibc.  What should I put in?  We
can require newer binutils to build glibc - no problem.  But losing
backward compatibility is a big deal.

Andreas