Bug#932287: glib2.0: FTBFS on mips64el: linking 32-bit code with 64-bit code

[YunQiang Su]

Control: reassign -1 binutils

Index: binutils-2.32.51.20190707/bfd/elfxx-mips.c
===================================================================
--- binutils-2.32.51.20190707.orig/bfd/elfxx-mips.c
+++ binutils-2.32.51.20190707/bfd/elfxx-mips.c
@@ -12193,6 +12193,11 @@ mips_set_isa_flags (bfd *abfd)
   switch (bfd_get_mach (abfd))
     {
     default:
+      if (ABI_N32_P (abfd) || ABI_64_P (abfd))
+        val = E_MIPS_ARCH_3;
+      else
+        val = E_MIPS_ARCH_1;
+      break;
     case bfd_mach_mips3000:
       val = E_MIPS_ARCH_1;
       break;

Simon McVittie <smcv at debian.org> 于2019年7月18日周四 下午8:29写道：
>
> Control: severity -1 normal
>
> On Thu, 18 Jul 2019 at 16:04:36 +0800, YunQiang Su wrote:
> > Simon McVittie <smcv at debian.org> 于2019年7月18日周四 上午2:03写道：
> > > Looks like plain objcopy produces MIPS-I objects, whereas invoking it
> > > in the normal way via the compiler frontend produces MIPS64r2 objects:
> > >
> > > (sid_mips64el-dchroot)smcv at eller ~/glib % file debian/build/deb/gio/tests/bcb7ac7@@actions at exe/actions.c.o
> > > debian/build/deb/gio/tests/bcb7ac7@@actions at exe/actions.c.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), with debug_info, not stripped
> > > (sid_mips64el-dchroot)smcv at eller ~/glib % file debian/build/deb/gio/tests/test_resources2.o
> > > debian/build/deb/gio/tests/test_resources2.o: ELF 64-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped
>
> For now I've disabled that test via
> debian/patches/GIO-tests-Don-t-do-clever-tricks-with-objcopy.patch. Please
> drop that patch if you want to test potential fixes.
>
> > I guess you are right, objcopy doesn't alter the object file correctly.
> > We need to patch it.
>
> Here's a minimal reproducer, which demonstrates that the problem is
> actually in (how GLib invokes) ld, not objcopy:
>
> Create an ordinary object file with 4 bytes of data named "foo", for
> comparison:
>
> $ cat > 932287.c <<EOF
> int foo = 0x12345678;
> EOF
> $ cc -c -o 932287.o 932287.c
> $ file 932287.o
> 932287.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), not stripped
> $ objdump -x 932287.o
> ...
>
> Create an object file from a raw binary with 4 bytes of data named "foo":
>
> $ xxd -r - 932287.bin <<EOF
> 00000000: 7856 3412
> EOF
> $ ld -r -b binary 932287.bin -o 932287-raw.o
> $ file 932287-raw.o
> 932287-raw.o: ELF 64-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped
> $ objdump -x 932287-raw.o
> ...
> $ objcopy --add-symbol foo=.data:0 932287-raw.o 932287-with-symbol.o
> $ file 932287-with-symbol.o
> 932287-with-symbol.o: ELF 64-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped
> $ objdump -x 932287-with-symbol.o
> ...
>
> Presumably when ld is invoked via the gcc compiler driver it does something
> that is more suitable for mips64el?
>
> Regards,
>     smcv



-- 
YunQiang Su