REMOVEUNUSED问题第二弹

erci***

前情提要：
解决编译器【REMOVEUNUSED选项】，可能错误移除问题，现象是感觉复位了 - 仿真/编译器/汇编器/头文件 国芯人工智能技术交流网站 - AI32位8051交流社区

欢迎各位提议更好的解决措施~

问题现象：

1.usb打印失败，或识别失败
2.任何调用strlen\memset\printf等标准库函数的应用都可能异常

map差异：
strlen\vsprintf\printf_usb等函数的EDATA资源被“R E M O V E D     S E G M E N T S ”?


临时解决措施：

之前修改头文件的措施无法完全规避此问题，即使加上strlen也不行。
当前有效措施：main文件中显示声明异常函数的别名指针。

牺牲ROM的措施：取消使用REMOVEUNUSED
牺牲RAM但可能更有效的措施：声明NOOVERLAY

问题复现工程：
REMOVEUNUSED_DEBUG.zip (764.34 KB, 下载次数: 5)

2025-12-22 20:15 上传

点击文件名下载附件

感谢网友“路过(xinxinsky)”提供的问题案例和声明别名措施！

_奶***

早就已经用上 NOOVERLAY 命令了  

REMOVEUNUSED命令确实要基于overlay功能，如果overlay不能正确分析函数的调用的话，那确实会造成功能异常。
那是不是可以通过修改调用树的方式，尝试解决这个问题呢？

当然用NOOVERLAY 命令也算是解决OVERLAY功能问题的方法。

由此对于闭源的lib文件一直都不太感冒。无法看到程序源码，也就不能对其进行精简，去掉或者关闭暂时不使用的函数。

erci***

_奶*** 发表于 2025-12-23 09:00
早就已经用上 NOOVERLAY 命令了  

REMOVEUNUSED命令确实要基于overlay功能，如果overlay不能正确分析函数 ...

1L案例是从FATFS开源代码中剥离出来的，可以说防不胜防


想到一个后拦截策略，在after build脚本中扫描map文件，检测是否*DEL*标准库函数产生告警：

_奶***

erci*** 发表于 2025-12-23 09:12
1L案例是从FATFS开源代码中剥离出来的，可以说防不胜防

emmm 编译后了，，好像也就只有提醒一下了，，