问题标签 [eabi]

我正在编写 c++ 代码以在 ARM cortex a9 CPU 上运行。我的代码链接到使用软浮点编译的封闭源 3rd 方库。我正在运行一个 cortex-a9 ARM cpu。

我注意到如果我使用 gcc 标志-mfloat-abi=softfp 编译我的代码，它的运行速度要比使用 -mfloat-abi=hard 编译快得多。

我认为硬浮动应该总是更快。是否有意义？

如何优化这些库调用？

谢谢！

一些注意事项：

• 库接口仅由整数、字符串和指针构成，并且工作正常。
• 加速大约是 x8，有利于 softfp。
• 关于二进制文件的 readelf 平台相关信息：

第三方库：

我的二进制文件：

我已经建立了一个环境。我倾向于在链接时获得无法识别的文件格式。我已启用详细信息，如果有人对此有答案，请告诉我。

01:14:38 ** 为项目 testerr 构建配置调试 ** make -j all 'Building target: testerr.elf' 'Invoking: Cross ARM C Linker' arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-部分 -fdata-sections -g3 -nostartfiles -nodefaultlibs -nostdlib -Xlinker --gc-sections -Xlinker --print-gc-sections -s -Wl,-Map,"testerr.map" -Xlinker --cref -v - o “testerr.elf” ./Src/main.o ./Src/stm32f4xx_hal_msp.o ./Src/stm32f4xx_it.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_adc.o . /Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_adc_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_can.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cortex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_crc.o ./Drivers/STM32F4xx_HAL_Driver/Src /stm32f4xx_hal_cryp.o 。/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cryp_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dac.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dac_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dcmi.o ./Drivers/STM32F4xx_HAL_Driver/Src /stm32f4xx_hal_dma.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma2d.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dma_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_eth.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.o ./ Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash_ramfunc.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_gpio.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_hash.o ./Drivers/STM32F4xx_HAL_Driver/Src/ stm32f4xx_hal_hash_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_hcd。o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2c.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2c_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2s.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2s_ex.o ./Drivers/STM32F4xx_HAL_Driver /Src/stm32f4xx_hal_irda.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_iwdg.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_ltdc.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_msp_template.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_nand.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_nor.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pccard.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd_ex.o ./Drivers/STM32F4xx_HAL_Driver/ Src/stm32f4xx_hal_pwr.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pwr_ex.o 。/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rng.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rtc.o ./Drivers/STM32F4xx_HAL_Driver/Src /stm32f4xx_hal_rtc_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sai.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sd.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sdram.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_smartcard.o ./ Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_spi.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_sram.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim_ex.o ./Drivers/STM32F4xx_HAL_Driver/Src/ stm32f4xx_hal_uart.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_usart.o 。/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_wwdg.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_fmc.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_fsmc.o ./Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_sdmmc.o ./Drivers/STM32F4xx_HAL_Driver/Src /stm32f4xx_ll_usb.o ./Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.o
使用内置规范。COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=c:/program\ files\ (x86)/gnu\ tools\ arm\ embedded/4.8\ 2014q2/bin/../lib/gcc/arm-none-eabi/4.8 .4/lto-wrapper.exe 目标：arm-none-eabi 配置：/home/build/work/GCC-4-8-build/src/gcc/configure --build=i686-linux-gnu --host =i686-w64-mingw32 --target=arm-none-eabi --prefix=/home/build/work/GCC-4-8-build/install-mingw --libexecdir=/home/build/work/GCC- 4-8-build/install-mingw/lib --infodir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir =/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/home/build/work/GCC-4-8- build/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/home/build/work/GCC-4-8-build/install-mingw/share/doc/gcc-arm- none-eabi/pdf --enable-languages=c,* [testerr.elf] 错误 1

01:14:39 构建完成（耗时 627 毫秒）

我必须在带有 ARM Cortex A8 的项目中使用为 ARM Cortex M4 预编译的库。链接器自然会给我一个错误：

file "..." has a Tag_CPU_arch_profile attribute value of "77" that is different than one previously seen ("65"); combining incompatible files

我可以使用 arm-none-eabi-objcopy 来转换库吗？它不包含特定于外围设备或微控制器本身的代码。两者都是ARM。似乎有可能，但如何？

您好，我是 NDK 和使用 Android 应用程序进行 C/C++ 开发的新手。我的 android 应用程序在用 c/c++ 编译 android 应用程序时遇到问题。我为我的 sqlite 添加了一些自定义库。谁能解释我的项目发生了什么，我需要用我的 MK 文件配置什么吗？我将此添加到我的 mk 文件APP_ABI := armeabi armeabi-v7a

这是我的 Android.mk 文件

当我开始运行我的项目时，armeabi-v7a 库会在编译中自动删除。

我用的是NDK R10b

为了清楚起见，这两个库在不同的项目中工作，但是当我将它们组合起来时，它在编译我的 android 应用程序时删除了 armeabi-v7a 下的 HERE-Map 库。

希望有人可以帮助我我很困惑..

谢谢！

前言：我的构建系统基于 Ubuntu 14.04 LTS 服务器版

在为arm-none-eabi工具链交叉编译 binutils 时，我遇到了一个常见问题。

从以下位置下载源代码后：

https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q3-update/+download/gcc-arm-none-eabi-4_8-2014q3-20140805-src.tar.bz2

我提取了 tarball 并使用以下命令修补了 zlib：

根据捆绑的 PDF 指南的说明。然后我应用了这个sed补丁：

并启动了./build-prerequisites.sh --skip_mingw32和./build-toolchain.sh --skip_mingw32脚本。

尽管./build-prerequisites.sh --skip_mingw32工作正常，但工具链脚本以 binutils 安装过程中的错误结束：

我还通过将make调用替换为调用来编辑第二个脚本，make MAKEFINFO=true但出现此错误...

....有什么建议吗？到目前为止，我一直在谷歌搜索，发现这些是使用 Ubuntu 发行版时常见的问题，但我仍然找不到解决方案。

在此先感谢，阿图罗

在被堆栈对齐问题困扰之后，我开始想知道堆是否也应该对齐到 8 个八位字节的边界。

ARM Cortex EABI 规定，对于所有对外部函数的调用，堆栈必须是 8 位对齐的。我找不到任何关于堆对齐是否有任何限制的信息。似乎有一些建议表明堆也应该按 8 对齐，但大多数公开可用的内存管理代码都将它按 4 对齐。

堆栈对齐要求不应与堆对齐有任何关系（只要遵守字边界），因为在堆和堆栈之间复制时不会保留对齐。另外，我想不出为什么编译器在指向 8 个八位字节宽的项目时应该限制为 8 个对齐的指针。

任何人都可以确认 4 字节对齐对于堆来说是足够的吗？

我有没有来源的 ELF ARM EABI 文件。它是二进制 .so 文件。

如何扩大文件段 .text 的大小？

我知道这个二进制文件中的这个中断代码，但现在它不是问题。

我从第三方公司获得了 .so 库，该公司使用 android ndk 来构建它，我应该调用这个库中定义的一些函数。

我能够编译代码并且链接也正确发生。然而，函数调用并没有真正发生，即我在调用函数时没有收到任何错误，但实际上它没有调用函数。我可以这么说，因为它没有改变作为输入传递的大小，而它是导出函数的输出。

我该如何调试呢？这与编译器名称修饰有关吗？

我正在使用安卓棒棒糖。同样的机制也在 kitkat 中起作用。

我正在开发一个在嵌入式设备上使用 Rust 的项目，我正在尝试用 Rust 编写可以从 C 调用的函数。我在没有标准库的情况下编译项目，或多或少遵循本教程：Embedded Rust Right现在！

我的 Rust 代码可以很好地编译为 .o 文件，但是在尝试使用 arm-none-eabi-ld 将 C 和 Rust 目标文件链接在一起时遇到了麻烦。我收到几个类似于这些的错误：

最让我困惑的是，即使我只是将目标文件链接在一起，错误也引用了我的 Rust 代码和来自 libcore 的代码。

有谁知道这些错误的含义以及为什么链接器无法解决这些问题？谢谢！

我正在使用 ARM_EABI 交叉编译器来编译使用 pthread 在 ARM Cortex A9 模拟中运行的代码。虽然我能够毫无问题地编译它（就像我对其他非 pthread 应用程序所做的那样，在模拟中运行良好），但在尝试在模拟中运行我的 pthread 应用程序时出现错误消息ARM（将 Linux 作为操作系统运行）。如下：

./pttest.exe: /lib/libpthread.so.0: 没有可用的版本信息（./pttest.exe 需要）

我进行了研究，发现这是因为它是一个动态库，并且我正在使用比我的模拟器上可用的版本更高的版本编译应用程序。

我的问题是：如何强制我的交叉编译器使用与我的模拟器相同的 pthread lib 版本来编译应用程序？有什么地方可以下载不同版本的 pthreads 吗？以及如何设置？

对不起，我是那个领域的新手。