All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: "Steven J. Hill" <sjhill@cotw.com>, linux-mips@oss.sgi.com
Subject: Re: Question on the binutils tradlittlemips patch
Date: Sun, 22 Apr 2001 22:19:53 -0400	[thread overview]
Message-ID: <20010422221953.A9097@nevyn.them.org> (raw)
In-Reply-To: <20010422180718.A6180@foobazco.org>; from wesolows@foobazco.org on Sun, Apr 22, 2001 at 06:07:18PM -0700

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

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 #2: glibc-mips-abi.patch --]
[-- Type: text/plain, Size: 1400 bytes --]

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. */
+
 /*
  * MIPS libraries are usually linked to a non-zero base address.  We
  * subtract the base address from the address where we map the object
@@ -76,6 +79,7 @@
 			  (l)->l_info[DT_MIPS(BASE_ADDRESS)]->d_un.d_ptr : 0)
 #else
 #define MAP_BASE_ADDR(l) 0x5ffe0000
+#endif
 #endif
 
 /* If there is a DT_MIPS_RLD_MAP entry in the dynamic section, fill it in

  reply	other threads:[~2001-04-23  2:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-18 18:19 Question on the binutils tradlittlemips patch Daniel Jacobowitz
2001-04-18 20:11 ` Andreas Jaeger
2001-04-18 21:03   ` Daniel Jacobowitz
2001-04-18 20:47 ` Steven J. Hill
2001-04-18 20:37   ` Daniel Jacobowitz
2001-04-23  1:07     ` Keith M Wesolowski
2001-04-23  2:19       ` Daniel Jacobowitz [this message]
2001-04-23  4:23         ` Keith M Wesolowski
2001-04-23  4:34           ` Daniel Jacobowitz
2001-04-23  5:54             ` Andreas Jaeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010422221953.A9097@nevyn.them.org \
    --to=dan@debian.org \
    --cc=linux-mips@oss.sgi.com \
    --cc=sjhill@cotw.com \
    --cc=wesolows@foobazco.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.