问题标签 [newlib]

我想为树莓派做一个操作系统，我需要一个交叉编译器。我决定在 Mac OS X 上构建它，并使用 GNU 编译器工具链和“arm-none-eabi”目标。

在构建 binutils 并安装了一些其他依赖项之后，我开始构建交叉编译器。我正在使用 GCC 版本 6.2.0，当我运行“make all-gcc”时，该过程失败并返回以下错误。

但是，我不明白告诉我使用 fbracket-depth 设置更高的括号嵌套级别意味着什么。

我应该把这个 fbracket-depth 放在哪里，我应该设置多高？

我是 STM32F103 世界的新手。我有一个 STM32F103 的演示代码，我正在使用 arm-none-eabi 来编译它。

我尝试了可以​​在 Google 上找到的内容，但到目前为止没有任何效果。我已经花了三天时间解决这个问题。

任何人都可以给我一个运行良好的 printf 演示代码吗？

我的makefile的一部分：

这是我的问题：

介绍

我目前正在尝试在 ARM 处理器上执行一些基本代码。由于我目前（可能很长一段时间）周围没有任何 ARM 硬件，所以我已经使用 QEMU（一个 ARM 仿真器）有几天了，我不得不说，它就像一个魅力. 但是使用 QEMU，我感觉就像拔剑杀苍蝇一样。所以我寻找了一些更轻的模拟器，并发现了 ARMulator。

“ARMulator 是一系列程序，可模拟各种 ARM 处理器及其支持架构的指令集。ARMulator 透明地连接到兼容的 ARM 调试器，以提供独立于硬件的 ARM 软件开发环境。通过远程调试接口 (RDI) 进行通信。”<br>（来源： http: //infocenter.arm.com/help/index.jsp ?topic=/com.arm.doc.dai0032f/index.html ）
“准确度很好，虽然它被归类为周期计数准确而不是周期准确，这是因为 ARM 流水线没有完全建模（尽管寄存器互锁是）。解决方案是一条指令，因此当单步执行时，寄存器互锁被忽略，并且返回的循环计数与程序仅运行时不同，这是不可避免的。”<br>（来源：https://en.wikipedia。 org/wiki/ARMulator )

环境

从那里，我尝试了几个 ARMulator 版本。不得不说周围没有很多，事实上我只尝试了3个版本（名字不是官方的，这只是我给他们起的一个名字来识别他们）：
-XYZ Armulator：https ://github.com/xyz /armulator 2016-02-20
- SourceForge Armulator：https ://sourceforge.net/projects/armulator/ 2013-04-26
- Phanrahan Armulator：https ://github.com/phanrahan/armulator 2014-11-11

我不确定这些版本是官方的，我想我在不同的网站上已经多次看到有一些版本是真正官方的，可能是专有的，并且包含的​​工具超出了所需的工具。以下是我正在谈论的一些示例：
- 在 ARM Connected Community 上，他们谈论了一个 RealViewDevelopmentSuite，它似乎包含 ARMulator：https
://community.arm.com/message/12272#12272 - ...当我添加其他人时再次找到其中一个但这些解决方案不是免费的。

现在关于工具链。我发现的资源中说明了两个不同的工具链：
- Arm-elf-abi：在 XYZ ARMulator GitHub 上说明，建议使用此命令（$ arm-elf-gcc -mthumb -Bstatic -o）进行编译二进制可执行文件。
我找到的唯一版本是适用于 Windows 的……遗憾的是，我找不到适用于 Unix 的版本。
- Arm-none-eabi：在本教程中说明：http ://www.bravegnu.org/gnu-eprog/hello-arm.html ，这是我一直在使用 QEMU 的那个。我在某处读过在编译 ARM 程序集时不需要 Arm-elf 工具链，而 Arm-none 对于这种情况就足够了。

我测试的两个程序尽可能简单：

组装中的一个：helloarm.s

C中的一个：test.c

编译过程

起初，我使用了与本教程中解释的 QEMU 相同的方法：http ://www.bravegnu.org/gnu-eprog/hello-arm.html 。在 QEMU 上，一切正常，但仿真过程略有不同。在执行 QEMU 之前，我必须先将二进制文件加载到 RAM 中。启动 ARMulator ($ armulator ) 的方式不同，我想自动加载的二进制文件是 RAM。

我尝试了三种不同的编译方式，不确定哪种最合适。这里是：

集会 ：

我们现在应该有两个“二进制文件”，一个 .bin 和一个 .elf。
我仍然不知道有什么区别。需要多读一些。

C ：

一个额外的：
我还尝试了本教程中解释的以下方法，这让我觉得 Armulator 是用来执行 .elf 二进制文件的。使用此方法创建的文件称为 c_entry。
https://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ 问题是一样的。

从那时起，我们有 6 个二进制文件：

• helloarm.bin

• helloarm.elf

• 主精灵

• a.out

• c_entry.bin

• c_entry.elf

问题

将 SourceForge 和 Phanrahan Armulator 与任何二进制文件（elf 或 bin）一起使用时：

$ ./armulator asm-helloarm.bin
打开文件 00000000.bin出错
$ ./armulator a.out
打开文件 00000000.bin 出错
$ ./armulator helloarm.elf
打开文件 00000000.bin 出错

使用 XYZ Armulator 时：

• 使用 helloarm.elf 二进制文件或任何 .elf 文件：

  $ armulator helloarm.elf

  错误：代码段外：0x24
  * `armulator' 中的错误：双重释放或损坏（顶部）：0x0000000001000550 *
  ======= 回溯：=========
  /lib/x86_64-linux- gnu/libc.so.6(+0x77725)[0x7f0f32cf4725]
  /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f0f32cfcf4a]
  /lib/x86_64-linux-gnu/libc.so.6( cfree+0x4c)[0x7f0f32d00abc]
  armulator[0x40489d]
  armulator[0x4022d2]
  armulator[0x401f3a]
  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f0f32c9d830]
  armulator[0x402109]
  ===== == 内存映射：========
  00400000-0040e000 r-xp 00000000 08:01 3802861 /usr/local/bin/armulator
  0060d000-0060e000 r--p 0000d000 08:01 3802861 /usr/local/bin/armulator
  0060e000-0060f000 rw-p 0000e000 08:01 3802861 /usr/local/bin/armulator
  00fe4000-01016000 rw-p 00000000 00:00 0 [HEAP]
  7F0F2C0000-7F0F2C021000 RW-P 00000000 00:00 0
  7F0F2C02C02C02C021000-7F0F0F30000000----- P 00000000 00:00 00:00 0
  7F0F0F0F32974000-7F0F0F0F32A7CPE00S r-ib xp 000/14-lib r-ib xp 0000000000000000000000000000000000000000000000000000000000000000000000000000000来so
  7f0f32a7c000-7f0f32c7b000 ---p 00108000 08:01 3281469 /lib/x86_64-linux-gnu/libm-2.23.so
  7f0f32c7b000-7f0f32c7c000 r--p 00107000 08:01 3281469 /lib/x86_64-linux-gnu/libm- 2.23.so
  7F0F32C7C000-7F0F32C7D000 RW-P 00108000 08:01 3281469/LIB/x86_64-linux-gnu/libm-2.23.so 7f0f0f32c7d000f32c7d000-7d000-7f32 000f32e32ebib
  yuns r-xpp 00887878878788788788787887888788788787.132.32/liB
  7f0f32e3d000-7f0f3303c000 ---p 001c0000 08:01 3281399 /lib/x86_64-linux-gnu/libc-2.23.so
  7f0f3303c000-7f0f33040000 r--p 001bf000 08:01 3281399 /lib/x86_64-linux-gnu/libc-2.23 。
  _
  _
  _ lib/x86_64-linux-gnu/libgcc_s.so.1
  7F0F3305C000-7F0F3325B000 --- P 00016000 08:01 3281437/LIB/
  x86_64-linux-gnu/libgcc_so.sso.1 7F0F333255B000-7F00S-7F00 1
  7f0f3325c000-7f0f333ce000 r-xp 00000000 08:01 3672061 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
  7f0f333ce000-7f0f335ce000 ---p 00172000 1/usr/lib/08:01 -gnu/libstdc++.so.6.0.21
  7f0f335ce000-7f0f335d8000 r--p 00172000 08:01 3672061 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
  7f0f335d8000-7f00-p:0017000 r 3672061 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
  7f0f335da000-7f0f335de000 rw-p 00000000 00:00 0
  7f0f335de000-7f0f33604000 r-xp 00000000 08:01 3281371 /lib/x86_64-linux-gnu/ld-2.23.so
  7f0f337e1000-7f0f337e6000 rw-p 00000000 00:00 0
  7f0f33800000-7f0f33803000 rw-p 00000000 00:00 0
  7f0f33803000-7f0f33804000 r--p 00025000 08:01 3281371 /lib/x86_64-linux-gnu/ld-2.23.so
  7f0f33804000-7f0f33805000 rw-p 00026000 08:01 3281371 /lib/x86_64-linux-70/ldso-2.23.so
  7f0f33805000 7F0F33806000 RW-P 000000 00 00 00 000 0
  7FFC24C119000-7FFC24C3AA000 RW-P 00000000000000000000000000000000 :00 0 [stack ]
  7ffc24000-7ffc24ca600s
  vdso]
  ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
  中止（核心转储）

• 使用 helloarm.bin 二进制文件：

$ armulator helloarm.bin
分段错误（核心转储）

• 使用 GCC 编译的 C 二进制文件：

$ armulator a.out
意外指令：

可能的原因
- ARMulator 不知道如何解码某些指令。可能是这种情况，但我的程序似乎太基础了……它什么也不做，返回 0……<br> - 我使用了错误的工具链，或者错误地使用了正确的工具链。
- 不应以这种方式使用 Armulator。

注意
使用 arm-none-eabi-gdb 运行二进制文件时，我无法运行或启动程序。只有这个命令有效：target，但它只会将目标文件重置为已经选择的二进制文件。
当我键入 start 时，它显示“未加载符号表。使用“文件”命令。”</p>

提前感谢您的帮助，或者至少感谢您的阅读，
希望我不是唯一一个在 Armulator 上遇到困难的人。

问候，
约翰

sigemptyset在 Newlib 下的 Cygwin 上使用时，我们发现编译器错误。该错误发生在 C++ 编译器中，但仅在-std=XXX使用时发生。如果没有标准选项，测试程序将按预期编译和执行。

测试程序如下，感兴趣的 Cygwin 标头如下。我在 Cygwin 标题中没有看到任何可疑之处。

我尝试过像#define _GNU_SOURCEand之类的技巧#define _XOPEN_SOURCE 700。我还尝试过使用全局和std命名空间等技巧。相关，请参阅-D_XOPEN_SOURCE 做什么/意味着什么？和c++11 中的命名空间问题？.

是什么导致编译失败，我该如何解决？

没有 a -std=XXX，它会导致：

使用-std=XXX，它会导致：

当尝试sigemptyset在全局命名空间中使用时：

使用-std=gnu++03和朋友时情况变得更糟。

我想.symtab用 gdb 调试器加载到内存中。

正常部分最多需要两个步骤（对于某些部分，例如.text, .data... ，可以跳过第 1 步，因为 ld 自动设置）：

1 - 将 Alloc 标志（在特殊部分的情况下）设置为 ELF 中的部分。这可以以这种方式对正常部分进行。

2 - 设置该部分的地址。对于正常部分AFAIK，这可以通过两种方式完成

A - 在 LD 脚本中指定段内存区域，例如文本段：

B - 再次使用 objcopy

因为.symtab是由链接器自动生成的，所以我不能将其视为正常部分，因此上述步骤均无效。

有谁知道如何解决这个问题？

我已经成功地实现了一个解决方法来生成一个新的精灵来剥离所有不需要的部分，这很有效，但是你必须加载两个精灵，我正在寻找一个更清洁的解决方案。

I am using the STM32F746NG microcontroller from STMicroelectronics. This device is based on the ARM Cortex-M7 architecture. I invested quite some time in understanding the linkerscript from example projects. I figured out the basics, but I still cannot grasp big parts of it. Please help me to understand those parts.

Start of the linkerscript

The linkerscript starts as follows:

Vector table and program code

After defining the memory areas, the linkerscript proceeds with defining the sections. The first section defined in the linkerscript is the vector table. It has to end up in the first bytes of the flash memory.

After the vector table is inserted, it's time for the program code:

The linkerscript defines the e_text global symbol that represents the address where the program code in flash ends.

Constant data

The read-only data ends up in the flash memory as well (it makes no sense to put it in RAM, which is volatile). The linkerscript defines that the .rodata section should be in flash:

Mysterious sections in flash

After defining where the constant read-only data should go, the linkerscript defines that a few 'mysterious' sections should end up in flash as well:

I have no idea what those sections are. So let this be the first question. What are these sections, and in what object files do they show up? As you know, the linkerscript needs to link together some object files. I have no idea in what object files these mysterious sections exist:

• .ARM.extab
• .ARM
• .preinit_array
• .init_array
• .fini_array

This is the end of allocations to the flash memory. The linkerscript continues with defining sections that end up in the RAM.

Sections in RAM

The .data and .bss sections are clear to me. No questions about this.

The linkerscript defines also a ._user_heap_stack section:

Apparently this section is not used immediately. It is only defined to check if the RAM has still enough space for the stack and the heap. A linker error is thrown when this is not the case (the . exceeds the top RAM address).

The end of the linkerscript

This is how the linkerscript ends. And honestly, I have no idea what it does. So this is the second question: What does the following mean?

我正在尝试交叉编译一个文件以闪存到 Beaglebone Black 中。一切正常，但如果我尝试启用 FPU

我收到以下错误

我也试过了thumb mode，但我得到了同样的错误。当然，如果我删除了初始化 FPU 的部分代码，它就可以正常工作。

为什么我会收到这些错误？

生成文件

我在 Arch，内核 4.8.1

PS 我的教授使用linaro 交叉编译器，它工作得很好

我要做的就是从图像中提取一些符号并使用（链接）来自不同图像的符号。

使用 armccc/armlink，当指定 --symdefs= 时，它会创建包含符号及其地址的文件。
另一方面，如果您删除未使用的符号，它只会更新现有符号。如果您将此文件包含在编译中，它会将先前图像的符号与新图像链接起来。

但我找不到类似的 GNU 工具链（arm-none-eabi-）方法。如果我使用 arm-none-eabi-nm，它会创建类似于 armcc --symdefs 选项的符号列表，但无法找到将此符号列表用于第二个图像编译的方法。（也没有办法过滤没有 grep 的符号）。

其他选项似乎也使用 arm-none-eabi-objcopy 但也找不到如何将它与第二个图像编译一起使用。

在 GNU 工具链中，我们怎样才能做到这一点？任何想法？

另一方面，如果可能的话，我想将其应用于 Keil uVision IDE。谢谢。

该问题涉及 arm-none-eabi-g++ 6.2 并链接到 newlib-nano。

当我使用 预处理C 源时，目录中-specs=nano.specs的文件包括：newlib.hnewlib-nano

输出# 1 "/opt/gcc-arm-none-eabi-6_2-2016q4/arm-none-eabi/include/newlib-nano/newlib.h" 1 3 4（如预期）。这是因为该文件nano.specs包含（除其他外）这些行

但是如果我通过同一个编译器提供一个C++ 源

输出读取# 1 "/opt/gcc-arm-none-eabi-6_2-2016q4/arm-none-eabi/include/newlib.h" 1 3。

换句话说：specs 文件被忽略。

我知道我应该在 C++ 源代码中包含<cstring>而不是，<string.h>并且 GNU g++ 通常由…/arm-none-eabi-c++而不是调用，…/arm-none-eabi-gcc -x c++但我这样做是为了消除微小的差异。并且：这并没有改变问题。

问题：我必须在规范文件中添加什么才能让 C++ 文件包含newlib-nano/newlib.h？

维基百科说“Newlib 是一个用于嵌入式系统的 C 标准库实现”。好的，但是我在哪里可以找到它的最新佳能版本？即正确的真正完整版本。

此外，C 语言还有哪些其他库？你能给我他们的ISO编号吗？

我试图了解 C 语言存在哪些库类型/版本，因此我知道将来遇到它们时它们的含义。

我希望 C 标准库仅被称为 C 标准库，但并未使用，而且这些不同的名称（如 newlib）似乎不太容易破译。