Question on the binutils tradlittlemips patch

Question on the binutils tradlittlemips patch

[Daniel Jacobowitz]

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

Re: Question on the binutils tradlittlemips patch

[Andreas Jaeger]

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

Re: Question on the binutils tradlittlemips patch

[Daniel Jacobowitz]

On Wed, Apr 18, 2001 at 10:11:11PM +0200, Andreas Jaeger wrote:
> 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.

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.

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

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

Re: Question on the binutils tradlittlemips patch

[Steven J. Hill]

Daniel Jacobowitz wrote:
> 
> 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:
> 
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

Re: Question on the binutils tradlittlemips patch

[Daniel Jacobowitz]

On Wed, Apr 18, 2001 at 03:47:38PM -0500, Steven J. Hill wrote:
> Daniel Jacobowitz wrote:
> > 
> > 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:
> > 
> 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.

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.

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

Re: Question on the binutils tradlittlemips patch

[Keith M Wesolowski]

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.

-- 
Keith M Wesolowski <wesolows@foobazco.org> 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

Re: Question on the binutils tradlittlemips patch

[Daniel Jacobowitz]

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

Re: Question on the binutils tradlittlemips patch

[Keith M Wesolowski]

On Sun, Apr 22, 2001 at 10:19:53PM -0400, Daniel Jacobowitz wrote:

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

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.

-- 
Keith M Wesolowski <wesolows@foobazco.org> 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

Re: Question on the binutils tradlittlemips patch

[Daniel Jacobowitz]

On Sun, Apr 22, 2001 at 09:23:01PM -0700, Keith M Wesolowski wrote:
> On Sun, Apr 22, 2001 at 10:19:53PM -0400, Daniel Jacobowitz wrote:
> 
> > 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.
> 
> 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.

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

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

Re: Question on the binutils tradlittlemips patch

[Andreas Jaeger]

Daniel Jacobowitz <dan@debian.org> writes:

> On Sun, Apr 22, 2001 at 09:23:01PM -0700, Keith M Wesolowski wrote:
> > On Sun, Apr 22, 2001 at 10:19:53PM -0400, Daniel Jacobowitz wrote:
> > 
> > > 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.
> > 
> > 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.
> 
> Don't you wish?  My other hat is Debian, which can't just ditch
> 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
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj