ARM gentoo crossdev с uclibc: нужен OABI, а не EABI

Может ли кто-нибудь помочь с моей связью ARM + GCC + UCLIBC проблема с кроссдевом?

Также опубликовано на форумах Gentoo здесь: http://forums.gentoo.org/viewtopic-t-925012.html

Недавно меня назначили на проект, в котором исполняемые файлы были разработаны с использованием старого GCC с ОАБИ. Для справки, вот заголовок, выводимый readelf для исполняемого файла, который прекрасно работает в системе:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x9464
  Start of program headers:          52 (bytes into file)
  Start of section headers:          540956 (bytes into file)
  Flags:                             0x202, has entry point, GNU EABI, software FP
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         35
  Section header string table index: 32

Я создал кросс-компилятор, используя crossdev и последнюю версию gcc/binutils/linux-headers/etc. и с ЭАБИ.

$ crossdev arm-softfloat-linux-uclibceabi

Я с радостью начал заполнять свою локальную папку исполняемыми файлами, используя этот кросс-компилятор, только для того, чтобы позже попробовать исполняемый файл на моем оборудовании и обнаружить, что в итоге я получил ошибку сегментации. Я понял, только немного погуглив, что мне действительно нужен старый, устаревший ABI для uclibc: OABI. Мой предыдущий кросс-компилятор был примерно 2005 года.

В качестве еще одной точки отсчета, мои исполняемые файлы с eabi создавали заголовки из readelf, которые выглядели примерно так:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x8130
  Start of program headers:          52 (bytes into file)
  Start of section headers:          21284 (bytes into file)
  Flags:                             0x5000002, has entry point, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         21
  Section header string table index: 18

Хотя машина та же самая, ошибка сегментации не предоставить способ выполнить двоичный файл на цели.

Погуглив больше, я обнаружил, что может быть способ создать некоторый код с помощью компилятора eabi для устаревшей системы.Я был очень доволен, когда запустил эту команду:

$ arm-softfloat-linux-uclibceabi-gcc -mabi=apcs-gnu -static -c -o /mnt/arm_uclibc/tmp/test /mnt/arm/tmp/test.c && readelf -h /mnt/arm_uclibc/tmp/test

И в итоге получил:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          248 (bytes into file)
  Flags:                             0x600, GNU EABI, software FP, VFP
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         12
  Section header string table index: 9

В этот момент я начал нервничать и решил попробовать создать исполняемый файл с -mabi=apcs-gnu,

arm-softfloat-linux-uclibceabi-gcc -mabi=apcs-gnu -static -o /mnt/arm_uclibc/tmp/test /mnt/arm/tmp/test.c

И я получаю сообщение об ошибке компоновщика:

/usr/libexec/gcc/arm-softfloat-linux-uclibceabi/ld: error: Source object /tmp/ccDq2f6R.o has EABI version 0, but target /mnt/arm_uclibc/tmp/test has EABI version 5
/usr/libexec/gcc/arm-softfloat-linux-uclibceabi/ld: failed to merge target specific data of file /tmp/ccDq2f6R.o
collect2: ld returned 1 exit status

ВОПРОС : Это наводит меня на мысль, что мой EABI неверен и мне нужен OABI. Это правильно?

Я полагал, что дело обстоит именно так, поэтому я начал изучать uclibc через crossdev:

$ crossdev arm-softfloat-linux-uclibc -P -v

Я рад сообщить, что файлы, которые ДЕЙСТВИТЕЛЬНО компилируются в какой-то двоичный объект, имеют правильный заголовок elf. Так что я думаю, что это то, что я хочу.

Но это умирает во время компиляции для uclibc следующим образом:

make[1]: `lib/ld-uClibc.so' is up to date.
  LD libuClibc-0.9.33.2.so
libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
_fpmaxtostr.c:(.text+0xbc): undefined reference to `__nedf2'
_fpmaxtostr.c:(.text+0xe0): undefined reference to `__eqdf2'
_fpmaxtostr.c:(.text+0xfc): undefined reference to `__divdf3'
_fpmaxtostr.c:(.text+0x108): undefined reference to `__ltdf2'
_fpmaxtostr.c:(.text+0x17c): undefined reference to `__muldf3'
_fpmaxtostr.c:(.text+0x348): undefined reference to `__gedf2'
_fpmaxtostr.c:(.text+0x40c): undefined reference to `__fixunsdfsi'
libc/libc_so.a(__psfs_do_numeric.os): In function `__psfs_do_numeric':
__psfs_do_numeric.c:(.text+0x534): undefined reference to `__truncdfsf2'
libc/libc_so.a(close.oS):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
collect2: ld returned 1 exit status
make: *** [lib/libc.so] Error 1

Если я правильно разобрал ошибку, я полагаю, что

1) Рука Makefile.arch неправильно создает __aeabi_unwind_cpp_pr0, потому что файл создается только тогда, когда EABI установлен:

$ find . -name 'Makefile.arch' -exec grep -i -H -n 'pr1' "{}" \;
./uclibc-0.9.33.2/work/uClibc-0.9.33.2/libc/sysdeps/linux/arm/Makefile.arch:45: $(ARCH_OUT)/aeabi_sighandlers.os $(ARCH_OUT)/aeabi_unwind_cpp_pr1.o
$ find . -name 'aeabi_unwind_cpp_pr1.c*'
./uclibc-0.9.33.2/work/uClibc-0.9.33.2/libc/sysdeps/linux/arm/aeabi_unwind_cpp_pr1.c
$ cat ./uclibc-0.9.33.2/work/uClibc-0.9.33.2/libc/sysdeps/linux/arm/aeabi_unwind_cpp_pr1.c
#include 

attribute_hidden void __aeabi_unwind_cpp_pr0 (void);
attribute_hidden void __aeabi_unwind_cpp_pr0 (void)
{
}

attribute_hidden void __aeabi_unwind_cpp_pr1 (void);
attribute_hidden void __aeabi_unwind_cpp_pr1 (void)
{
}

attribute_hidden void __aeabi_unwind_cpp_pr2 (void);
attribute_hidden void __aeabi_unwind_cpp_pr2 (void)
{
}

Я полагаю, что исправление для этой ошибки:

--- Makefile.arch.old   2012-05-28 00:43:52.918708833 -0500
+++ Makefile.arch.new   2012-05-28 00:44:30.658708443 -0500
@@ -42,5 +42,6 @@
 libc-static-y += $(ARCH_OUT)/aeabi_lcsts.o $(ARCH_OUT)/aeabi_math.o \
        $(ARCH_OUT)/aeabi_sighandlers.o
 libc-nonshared-y += $(ARCH_OUT)/aeabi_lcsts.os $(ARCH_OUT)/aeabi_math.os \
-       $(ARCH_OUT)/aeabi_sighandlers.os $(ARCH_OUT)/aeabi_unwind_cpp_pr1.o
+       $(ARCH_OUT)/aeabi_sighandlers.os
 endif
+libc-nonshared-y += $(ARCH_OUT)/aeabi_unwind_cpp_pr1.o

2) Мягкое плавание в gcc не включается должным образом компоновщиком. Я не могу сказать, почему на данный момент.

$ find . -name '*.c' -exec grep -i -H -n nedf2 "{}" \;
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/mips/mips.c:11123:       set_optab_libfunc (ne_optab, DFmode, "__mips16_nedf2");
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/eqdf2.c:51:strong_alias(__eqdf2, __nedf2);
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/testsuite/gcc.c-torture/execute/gofast.c:32:int nedf2 (double a, double b) { return a != b; }
./gcc-4.5.3-r2/work/gcc-4.5.3/libgcc/config/rx/rx-abi-functions.c:41:int _COM_CMPNEd (double a, double b) { return __nedf2 (a, b) != 0; }
$ ls ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/
README    double.h       extendsftf2.c  fixsfti.c     fixunssfdi.c  floatdisf.c  floattitf.c    floatuntidf.c  lesf2.c   negtf2.c     single.h      trunctfdf2.c
adddf3.c  eqdf2.c        extendxftf2.c  fixtfdi.c     fixunssfsi.c  floatditf.c  floatundidf.c  floatuntisf.c  letf2.c   op-1.h       soft-fp.h     trunctfsf2.c
addsf3.c  eqsf2.c        fixdfdi.c      fixtfsi.c     fixunssfti.c  floatsidf.c  floatundisf.c  floatuntitf.c  muldf3.c  op-2.h       subdf3.c      trunctfxf2.c
addtf3.c  eqtf2.c        fixdfsi.c      fixtfti.c     fixunstfdi.c  floatsisf.c  floatunditf.c  gedf2.c        mulsf3.c  op-4.h       subsf3.c      unorddf2.c
divdf3.c  extenddftf2.c  fixdfti.c      fixunsdfdi.c  fixunstfsi.c  floatsitf.c  floatunsidf.c  gesf2.c        multf3.c  op-8.h       subtf3.c      unordsf2.c
divsf3.c  extended.h     fixsfdi.c      fixunsdfsi.c  fixunstfti.c  floattidf.c  floatunsisf.c  getf2.c        negdf2.c  op-common.h  t-softfp      unordtf2.c
divtf3.c  extendsfdf2.c  fixsfsi.c      fixunsdfti.c  floatdidf.c   floattisf.c  floatunsitf.c  ledf2.c        negsf2.c  quad.h       truncdfsf2.c
$ grep -i -H -n nedf2 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/eqdf2.c:51:strong_alias(__eqdf2, __nedf2);
$ grep -i -H -n eqdf2 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/eqdf2.c:35:CMPtype __eqdf2(DFtype a, DFtype b)
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/eqdf2.c:51:strong_alias(__eqdf2, __nedf2);
$ grep -i -H -n divdf3 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/divdf3.c:35:DFtype __divdf3(DFtype a, DFtype b)
$ grep -i -H -n ltdf2 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/ledf2.c:51:strong_alias(__ledf2, __ltdf2);
$ grep -i -H -n muldf3 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/muldf3.c:35:DFtype __muldf3(DFtype a, DFtype b)
$ grep -i -H -n gedf2 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/gedf2.c:35:CMPtype __gedf2(DFtype a, DFtype b)
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/gedf2.c:51:strong_alias(__gedf2, __gtdf2);
$ grep -i -H -n fixunsdfsi ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/fixunsdfsi.c:35:USItype __fixunsdfsi(DFtype a)
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/t-softfp:71:softfp_func_list := $(filter-out floatdidf floatdisf fixunsdfsi fixunssfsi \
$ grep -i -H -n truncdfsf2 ./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/*
./gcc-4.5.3-r2/work/gcc-4.5.3/gcc/config/soft-fp/truncdfsf2.c:36:SFtype __truncdfsf2(DFtype a)

Итак, я попытался заставить GCC построить для soft-float и связать его позже в сборке uclibc:

$ UCLIBC_CPU=ARM926T ACCEPT_KEYWORDS="arm" CPU_CFLAGS="-marm -march=armv5te -mtune=arm926ej-s -mabi=apcs-gnu -mno-thumb" EXTRA_FLAGS="-msoft-float -mfloat-abi=soft" UCLIBC_EXTRA_CFLAGS="${CPU_CFLAGS} ${EXTRA_CFLAGS}" STAGE1_CFLAGS="${EXTRA_CFLAGS}" CFLAGS="${EXTRA_CFLAGS}" crossdev -A arm -t arm-softfloat-linux-uclibc -P -v

Затем я проверил, использовались ли -msoft-float и -mfloat-abi=soft в любом Лог для компиляции.

$ find . -name '*.log' -exec grep -i -H -n msoft-float "{}" \;

$ find . -name '*.log'
./work/build/arm-softfloat-linux-uclibc/libgcc/config.log
./work/build/libcpp/config.log
./work/build/gcc/config.log
./work/build/fixincludes/config.log
./work/build/intl/config.log
./work/build/build-x86_64-pc-linux-gnu/libiberty/config.log
./work/build/build-x86_64-pc-linux-gnu/fixincludes/config.log
./work/build/libdecnumber/config.log
./work/build/libiberty/config.log
./work/build/config.log
./work/gcc-4.5.3/contrib/reghunt/examples/29478.log
./work/gcc-4.5.3/contrib/reghunt/examples/29906a.log
./work/gcc-4.5.3/contrib/reghunt/examples/29906b.log
./work/gcc-4.5.3/contrib/reghunt/examples/28970.log
./work/gcc-4.5.3/contrib/reghunt/examples/29106.log
./work/gcc-4.5.3/contrib/reghunt/examples/30643.log
./temp/elibtool.log
./temp/epatch_user.log
./temp/epatch.log
./temp/eclass-debug.log
./temp/build.log

Но я заметил, что --with-float=soft устанавливается в config.log, так что я считаю, что число с плавающей запятой должно было быть сгенерировано.
И я отмечаю -D__GCC_FLOAT_NOT_NEEDED в параметрах компиляции для gcc.

Я провел регрессию на GCC, чтобы увидеть, где произошел разрыв.

  1. gcc 4.x не работает с uclibc. -- начиная с 4.4.4-r2, uclibc имеет ошибку связывания с gcc -- до версии 4.4.4 gcc не отображался
  2. gcc-3.4.6-r2 работает при условии, что используется USE=-nptl

Для справки я запустил: бинутилс: 2.22-r1 Заголовок Linux: 3.3, 3.4 uclibc: 0.9.33.2 gcc: 3.2.3-r4, 3.3.6-r1, 3.4.6-r2, 4.1.4-r1, 4.3.3-r2, 4.4.2, 4.4.4-r2, 4.4.5, 4.4.6- р1, 4.4.7, 4.5.3-р2, 4.6.0, 4.6.1-р1, 4.6.2, 4.6.3

5
задан Brian Bruggeman 3 June 2012 в 03:31
поделиться