使用MacPorts我刚刚将arm-elf-gcc安装到我的MacBook Pro上。这完美无缺，一切似乎运行良好。
然而，在用C和C ++编译一个简单的hello world测试程序并尝试在目标板（运行Debian Linux的基于ARM9的板）上运行之后，它们会立即出错。
我有点担心如何调试这个，因为目标板有可用的工具和没有gdb。我已经使用Linux托管的交叉编译器成功构建并运行其他代码，因此它应该可以工作。
有什么想法吗？
根据我建立并运行gdbserver的建议，我在主机上的gdb中获得以下内容：
编程接收信号SIGSEGV，分段故障。 0x00000000在？ （）
我认为这可能是标准c库的一个问题所以我删除了任何调用并且只有一个空的main返回0，它是用 -Wall -g hello-arm.cpp -static编译的。作为测试，我使用Linux托管的交叉编译器编译了相同的源代码，它运行并退出正常。我能看到的唯一区别是Linux编译版本的大小超过了文件命令输出的两倍：
arm-elf-gcc：ELF 32位LSB可执行文件，ARM，版本1，静态链接，未剥离
arm - * - linux：ELF 32位LSB可执行文件，ARM，版本1，静态链接，适用于GNU / Linux 2.4.18，未剥离
答案 0 :(得分：2)
在这种情况下，通常的调试方法是在目标板上运行gdbserver，并使用在主机上运行的gdb连接到它（通过以太网）。
或者，您可以尝试比较Mac编译的“Hello World”程序和（工作）Linux编译程序中的程序集，看看有什么不同。
答案 1 :(得分：1)
经过几天的挖掘后，我开始更多地了解嵌入式编译器。我不太确定通过MacPorts安装的arm-elf-gcc与我在Linux机器上安装的arm-unknown-linux工具链之间的区别。我刚刚看到一个标题为“An introduction to the GNU compiler”的pdf，其中包含以下段落：
重要：使用GNU编译器 创建你的可执行文件并不完全 与使用GNU Linker相同， arm-elf-ld，你自己。原因是 那个GNU编译器是自动的 链接了许多标准系统 库到您的可执行文件中这些 库允许您的程序 与操作系统交互 使用标准C库函数， 使用某些语言功能和 操作（如分工）等 上。如果你想看到究竟是哪个 图书馆被链接到 可执行文件，你应该通过 详细的旗帜 -v到编译器。
这具有重要意义 嵌入式系统！这样的系统没有 通常有一个操作系统。 这意味着在系统中进行链接 图书馆几乎总是如此 毫无意义：如果没有经营 系统，例如，然后调用 标准的printf函数没有 很有道理。
因此，当我稍后回到我的开发机器时，我将确定与Linux构建链接的库，并将它们添加到arm-elf-gcc构建中。
当我有更多信息时，我会更新这个，但我只想记录我的发现，以防任何其他人遇到这些问题。