Binutils status on Linux/MIPS?

Binutils status on Linux/MIPS?

[MacGyver]

I've been watching the thread about the impending release of 2.11.1 and
H.J.'s and others comments on trying to fix/cleanup Linux/MIPS -- what
*EXACTLY* is the current status of the tree that's in CVS relative to
Linux/MIPS?  Can I expect it to generate valid binaries?  What's the
position on Linux/MIPS and 2.11.1 -- is it officially supported?  It
seems that there hasn't been a lot of time put into getting Linux/MIPS
into a usable/stable condition and in light of the impending deadline
for releasing 2.11.1 what's going to happen?

Here's why I ask...as of 3 weeks ago, the CVS tree was NOT generating
valid binaries on Cobalt Qubes and RaQ 2s.  One of the changes I noticed
was the binary output format seems to have changed for Linux/MIPS --
why?

On my Cobalt machines, with the version of binutils that ships on Qubes
and RaQ2's, ld --version produces:

GNU ld 2.8.1
Copyright 1997 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf32lmip
   elf32bmip
   mipslit
   mipsbig

And doing file /usr/bin/ld produces:

/usr/bin/ld: ELF 32-bit LSB executable, MIPS RS3000_BE - invalid byte
order, version 1, dynamically linked, stripped

However, using the latest (apparently) stable RPMs for mipsel-linux from
Maciej W. Rozycki (binutils 2.10.91) I get the following from ld
--version:

GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf32lsmip
   elf32bsmip
   mipslit
   mipsbig

And once again file /usr/bin/ld produces:

/usr/bin/ld: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte
order, version 1, dynamically linked (uses shared libs), stripped

What is the difference between elf32lsmip and elf32lmip?  Looking
through the parameter templates in ldscripts I don't see any major
obvious differences...but then again, I'm not overly familiar with the
inners of binutils.

And now...with the latest CVS as of about 8:30AM CDT, I can compile
binutils cleanly, but cannot get it to build any valid/executable
binaries that use shared libraries:

./ld-new --version produces:

lt-ld-new: error while loading shared libraries: failed to map segment
from shared object: cannot load shared object file: Invalid argument

Performing a file ./libs/ld-new gets:

./ld-new: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order,
version 1, dynamically linked (uses shared libs), not stripped

Building anything statically produces similar results.  Any
thoughts/help?

-HJD

Re: Binutils status on Linux/MIPS?

[Ian Lance Taylor]

"MacGyver" <macgyver@tos.net> writes:

I can't answer most of your questions, but I can answer this one:

> What is the difference between elf32lsmip and elf32lmip?  Looking
> through the parameter templates in ldscripts I don't see any major
> obvious differences...but then again, I'm not overly familiar with the
> inners of binutils.

The difference is the default entry symbol which is used.  For
elf32lmip, the linker expects to see an entry symbol named `start'.
For elf32lsmip, the linker expects to see an entry symbol named
`__start'.  The latter is appropriate for use on a typical Unix
system.

Ian

Re: Binutils status on Linux/MIPS?

[Alan Modra]

On Wed, Jun 13, 2001 at 03:27:00PM +0200, Maciej W. Rozycki wrote:
> 
>  Hmm, the patch is mostly for mips64*-linux

Which shows that I didn't look at it carefully enough :)  Just saw
ABI change, and said "AHA!"

Re: Binutils status on Linux/MIPS?

[Maciej W. Rozycki]

On Wed, 13 Jun 2001, Alan Modra wrote:

> Of these patches, only 3 have not already been applied, or in one case,
> a slightly different patch applied.  The three are:
> 
> binutils-2.9.5-configure.patch, which I think doesn't actually do anything.

 It changes the style of variable references, which helps to avoid
problems when expanded under a shell.  The patch was discussed with GCC
people once and they stated everything should be properly quoted already
and no expansion should happen.  Unfortunately, if quotes are present in a
string, e.g. passed as an argument to "--libdir", an expansion may still
happen.  I wasn't sure how to avoid it at that time and haven't looked at
the issue again since then.  The conclusion was to leave the script as is
not to cover the bug.

 Still I need the workaround for my packages and I will submit a better
patch once (if?) I develop it.

> binutils-2.10.91-20010116-libtool.patch, again doesn't do much but may
> be necessary for you, I'm not sure

 It's a workaround for the inability to regenerate configure scripts with
the released version of autoconf and libtool 1.3.5 needed a fix for
cross-compilation.  Otherwise one could just invoke `aclocal; autoconf' in
the affected dirs, as usual. 

> binutils-2.10.91-20010116-ulfc-mips.patch, which is an ABI change.
> It's likely that if your existing shared libs or dynamic linker were
> built using this patch, then every binary from that point would need
> to be built by a binutils with the patch.  I suspect this is the
> reason you've been having problems.

 Hmm, the patch is mostly for mips64*-linux -- it shouldn't affect the
mips*-linux target much, i.e. mips*-linux should be interchangeable.  For
mips*-linux it isn't really needed, I suspect, but I'm unsure as for
certain reasons I haven't tested post-2.10.91 binutils, yet.  I don't want
to drop the patch as I don't want to risk losing it -- someone might do
unnecessary duplicate work one day, then. 

 The patch is by Ulf Carlsson -- I contacted him with respect to it, but
he doesn't seem to be reachable these days.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Binutils status on Linux/MIPS?

[Alan Modra]

On Wed, Jun 13, 2001 at 12:16:03AM -0500, MacGyver wrote:
> 
> I'm attaching the collection of patches for your reference -- I haven't
> looked through them in detail yet, but I also know next to nothing about
> the binutils internals, so I doubt I'd be of much use.
> 
> Any thoughts?

Of these patches, only 3 have not already been applied, or in one case,
a slightly different patch applied.  The three are:

binutils-2.9.5-configure.patch, which I think doesn't actually do anything.

binutils-2.10.91-20010116-libtool.patch, again doesn't do much but may
be necessary for you, I'm not sure

binutils-2.10.91-20010116-ulfc-mips.patch, which is an ABI change.
It's likely that if your existing shared libs or dynamic linker were
built using this patch, then every binary from that point would need
to be built by a binutils with the patch.  I suspect this is the
reason you've been having problems.

Alan Modra