linux-mips
[Top] [All Lists]

Re: Problems generating shared library for MIPS using binutils-2.13...

To: linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: Problems generating shared library for MIPS using binutils-2.13...
From: "Steven J. Hill" <sjhill@realitydiluted.com>
Date: Mon, 04 Nov 2002 08:49:43 -0600
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.GSO.3.96.1021025185639.1121A-100000@delta.ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
Maciej W. Rozycki wrote:

Is every object or library mentioned on that line already marked as
MIPS-2 by readelf?  Even crt*, libc*?


I knew I was being stupid, crt* and libc* are mips1 *sigh*. Looks
like I have more work to do for my build system. Below is the verbose
output, but I think that's the problem for sure.


 Hmm, that's strange as a single mips2 object among mips1 ones should make
an executable/shared library be marked as mips2 and not mips1.  I wouldn't
worry in the long run, though, as I think this should be fixed in the
trunk as Richard Sandiford was working in these areas recently.  You might
want to do a verification to be sure, though.
I tried the trunk and got the same thing. I have made some additional
progress. First, I used H.J.Lu's patch for the most part:

   http://sources.redhat.com/ml/binutils/2001-10/msg00526.html

Specifically the part:

-  elf_elfheader (abfd)->e_flags &= ~(EF_MIPS_ARCH | EF_MIPS_MACH);
-  elf_elfheader (abfd)->e_flags |= val;
+  if (isa != 0 && (elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) == 0)
+    {
+      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_ARCH;
+      elf_elfheader (abfd)->e_flags |= isa;
+    }
+
+  if (cpu != 0)
+    {
+      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_MACH;
+      elf_elfheader (abfd)->e_flags |= cpu;
+    }

So, now when I am building 'zlib', the object files get built with:

  mipsel-linux-gcc -march=r6000 -fPIC -O3 -DHAVE_UNISTD_H -DUSE_MMAP

and then shared object creation uses:

  mipsel-linux-gcc -shared -Wl,-A,r6000,-v,-soname,libz.so.1 \
    -march=r6000 -o libz.so.1.1.4 adler32.o compress.o crc32.o gzio.o \
    compr.o deflate.o trees.o zutil.o inflate.o infblock.o inftrees.o \
    infcodes.o infutil.o inffast.o

with the verbose output of:

collect2 version 3.2 (MIPSel GNU/Linux with ELF)
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/bin/ld --eh-frame-hdr -EL -shared -o libz.so.1.1.4 /opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib/crti.o /opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/crtbeginS.o -L/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2 -L/opt/toolchains/uclibc/bin/../lib/gcc-lib -L/opt/toolchains/uclibc-crosstools-1.0.0/lib/gcc-lib/mipsel-linux/3.2 -L/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib -L/opt/toolchains/uclibc-crosstools-1.0.0/lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib -L/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../.. -A r6000 -v -soname libz.so.1 adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infblock.o inftrees.o infcodes.o infutil.o inffast.o -lgcc -lc -lgcc /opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/crtendS.o /opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib/crtn.o

The 'crt*' files and my C runtime are compiled with 'mips1', but as
Maciej correctly states in his reply, the output binary should be
the highest ISA value when mixing differing ISA objects.

I'm convinced the linker completely ignores '-A' for MIPS. In the '_bfd_mips_elf_final_write_processing' function in 'bfd/elfxx-mips.c'
If I print out the EF_MIPS_ARCH flags for the input BFD descriptor. It
is properly set to 'MIPS2', but when the case statement in '_bfd_mips_elf_final_write_processing' is traversed, it
uses the R3000/default case which means that the target CPU architecture
didn't get put into the BFD descriptor. So, I instead changed the ISA
if statement above to be:

if (((elf_elfheader (abfd)->e_flags & EF_MIPS_ARCH) != isa) && (isa != 0))
    {
      elf_elfheader (abfd)->e_flags &= ~EF_MIPS_ARCH;
      elf_elfheader (abfd)->e_flags |= isa;
    }

which then properly sets the ISA in the ELF header. My gut feeling
though is that we shouldn't have to do this as the target CPU
architecture should have been set properly for the incoming BFD.
Comments and suggestions welcome. Thanks.

-Steve


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