完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
你好， 我们在使用RT-Thread4.1.0的过程中，发现同样的源代码在scons编译后结果不同，这给我们带来了一些麻烦，因为源代码相同，编译生成的bin文件却不同。 刚开始所有编译生成的代码都能正常运行，后来我们遇到了一个版本的代码，编译结果会影响运行结果。 在编译出某个大小的hex的情况下可以正常运行， 在编译出另一大小的hex的编译结果下不能正常运行， 于是我们开始关注这个问题。 我们的代码连续编译得到的hex文件大小不同（连续编译5次就能复现了） RT-Thread官方发布的源代码连续编译的hex大小也不同（可能要连续编译20次左右能够复现） hex大小差异10~40个数字，但map和bin文件的差异超级大。 有什么办法可以让它在源文件相同的情况下，每次编译生成bin文件都相同吗？ 我们做过的尝试有： 1）改成单核编译，即scons -j8 改成scons -j1。结果：没有效果； 2）每次build前都清空上一次的编译结果，scons -c。结果：没有效果； 下面是一些有助于您更好理解问题的截图 1）scons执行目录： rt-thread-4.1.0bspSTM32stm32h750-armfly-h7-tool 2）编译生成文件对比图： 
0
|
|
相关推荐
7个回答
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
进一步看 arm-none-eabi-gcc 链接生成 rt-thread.elf 的命令行。能看到 o 文件的顺序不一样！
这样在 map 文件提现出来就是你看到的差异很多 再就是 elf 文件中二进制代码的位置差异，各种字符串内存位置的差异 但是，你要是说这个影响的程序运行结果，我保留意见。 要解决这个问题，能把 arm-none-eabi-gcc 命令行所有 o 文件的顺序固定下来就可以了 |
|
|
|
|
|
经过数十次的结果比对，好像只有两种结果。
|
|
|
|
|
|
这个影响程序的运行结果是有实验支撑的。源码没有上机跑过，我们的工程中不同的编译结果对应这不同的运行结果（其中一种会卡进Hardfault）。
源码编译后确实只有两种结果，我们移植后的工程不止两种，好在源码也已经能说明问题了。 原来这句话是提示已经编译过了的意思，学到了。 scons: `.’ is up to date. **我们正在找能把所有o文件的顺序固定下来的办法，试了好个链接选项都没有效果 |
|
|
|
|
|
后面得分析 scons 的源码了，怎么分支出来的这两种结果，可能是 scons 源码，也可能是 env ，也可能是 rt-thread tools 里。找到给 obj 文件排序的 py 代码应该可以解决
|
|
|
|
|
|
这个 pr 才是从根上解决问题的方法 |
|
|
|
|
你正在撰写答案
如果你是对答案或其他答案精选点评或询问，请使用“评论”功能。
AI模型部署边缘设备的奇妙之旅：如何在边缘端部署OpenCV
1591 浏览 0 评论
tms320280021 adc采样波形，为什么adc采样频率上来波形就不好了？
1112 浏览 0 评论
1557 浏览 0 评论
1402 浏览 0 评论
1044 浏览 0 评论
74628 浏览 21 评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
510
评论
淘帖
1828
