Может ли кто-нибудь помочь с моей связью 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, чтобы увидеть, где произошел разрыв.
Для справки я запустил: бинутилс: 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