从 Winarm 迁移到 Yagarto
这个问题肯定适用于这么少的人...
我正忙着将我的 ARM C 项目从 Winarm GCC 4.1.2 迁移到 Yagarto GCC 4.3.3。
我没想到有任何差异，并且都使用相同的 makefile 和 .ld 文件愉快地编译了我的项目。
然而，虽然 Winarm 版本可以运行，但 Yagarto 版本却不能。 处理器是 Atmel AT91SAM7S。
任何有关去哪里寻找的想法都将受到欢迎。 我认为我关于 makefile 是 makefile 的假设是不正确的，或者 Winarm 的 .ld 文件不适用于 Yagarto。
由于它们都是 GCC 工具链并且可能使用相同的链接器，因此它们肯定是兼容的。
TIA
结束。
This question must apply to so few people...
I am busy mrigrating my ARM C project from Winarm GCC 4.1.2 to Yagarto GCC 4.3.3.
I did not expect any differences and both compile my project happily using the same makefile and .ld files.
However while the Winarm version runs the Yagarto version doesn't. The processor is an Atmel AT91SAM7S.
Any ideas on where to look would be most welcome. i am thinking that my assumption that a makefile is a makefile is incorrect or that the .ld file for Winarm is not applicable to Yagarto.
Since they are both GCC toolchains and presumably use the same linker they must surely be compatable.
TIA
Ends.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这也可能是编译器行为上的细微差别：代码生成确实从 gcc 版本到 gcc 版本发生了变化，并且如果您的代码包含依赖于其语义的实现的片段，它很可能会以这种方式咬住您。 例如，数据的内存布局可能会发生变化，并且意外依赖它的代码可能会中断。
看到这种情况发生很多次了。
在编译中尝试使用不同的优化选项，看看是否有所不同。
It could also be a subtle difference in compiler behavior: code generation does change from gcc release to gcc release, and if your code contains pieces which are implementation-dependent for their semantics, it might well bite you in this way. Memory layouts of data might change, for example, and code that accidentally relied on it would break.
Seen that happen a lot of times.
Try it with different optimization options in the compile and see if that makes a difference.
WinARM 和 YAGARTO 都基于 gcc，应该平等对待 ld 文件。 而且两者都使用 gnu make 实用程序 - make 文件将以相同的方式处理。 您可以在此处和比较两个工具链="http://www.yagarto.de/" rel="nofollow noreferrer">这里。
如果您使用 OCD 运行项目，则 OpenOCD 调试器的实现之间存在差异。 此外，发送到调试器来配置它的命令也可能不同。
如果您生成十六进制文件，那么这可能会有所不同，因为两个工具链没有使用相同版本的 newlib 库。
为了安全起见，请确保在这两种情况下，正确的 binutils 都位于路径的第一个位置。
Both WinARM and YAGARTO are based on gcc and should treat ld files equally. Also both are using gnu make utility - make files will be processed the same way. You can compare the two toolchains here and here.
If you are running your project with an OCD, then there is a difference between the implementation of the OpenOCD debugger. Also the commands sent to the debugger to configure it could be different.
If you are producing an hex file, then this could be different as the two toolchains are not using the same version of newlib library.
In order to be on the safe side, make sure that in both cases the correct binutils are first in the path.
如果我是你，我会检查编译/链接器标志 - 特别是默认值。 不同的工具链具有不同的默认 ABI 或 FP 约定是很常见的。 它甚至可能使用您的 CPU 不支持的指令集扩展进行编译。
If I were you I'd check the compilation/linker flags - specifically the defaults. It is very common for different toolchains to have different default ABIs or FP conventions. It might even be compiling using an instruction set extension that isn't supported by your CPU.
我同意 gcc 和其他二进制文件 (ld) 应该相同或足够接近，以便您不会注意到差异。 但是启动代码无论是你的还是他们的，以及 C 库都可以产生很大的影响。 当尝试使用相同的源代码和链接描述文件时，足以区分成功和失败。 现在，如果这 100% 是您的代码，没有从 WinARM 或 Yagarto 使用任何库或任何其他文件，那么这没有多大意义。 3.xx 到 4.xx 是的，我必须重新旋转我的链接器脚本，但 4.1.x 到 4.3.x 我不记得那里有问题。
I agree that the gcc's and the other binaries (ld) should be the same or close enough for you not to notice the differences. but the startup code whether it is your or theirs, and the C library can make a big difference. Enough to make the difference between success and failure when trying to use the same source and linker script. Now if this is 100% your code, no libraries or any other files being used from WinARM or Yagarto then this doesnt make much sense. 3.x.x to 4.x.x yes I had to re-spin my linker scripts, but 4.1.x to 4.3.x I dont remember having problems there.