This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:TI C/C++编译器
我正在查看TI ARM优化C/C++编译器的支持库中的malloc()代码路径。
我研究的一个路径是在编译系统时malloc()如何运行,而没有分配堆(即指定--heap_size=0到链接器)。
如TI汇编器和TI编译器文档中所述,TI连接器:
链接器还会创建一个全局符号__SYSMEM_SIZE,并为其分配一个值,该值等于堆的大小(以字节为单位)。
浏览代码,特别是memory.c中的minit()代码,很明显该代码不能处理__SYSMEM_size的0。 如果__SYSMEM_SIZE为0,则调用malloc()会损坏内存。
但是,编译链_iS_正在尝试处理这种情况。 链接程序似乎强制最小大小为8。 如果指定--heap_size=0 (或者,大概--heap_size=7),TI链接程序将实际生成一个8字节的.sysmem段,并将__SYSMEM_SIZE设置为8。
我会而且我也会争辩说,这种在链接器内实现部分C库功能的方法不是完全的责任分离。
我单独认为,将部分功能放在链接器中会隐藏功能;能够查看C库源代码对我们非常有价值,但链接器更不透明。
最后,我认为这种行为令人困惑。 我本来希望能够写我自己的代码,可以对照0检查__SYSMEM_SIZE,以确定是否有任何堆编译到固件中。 不得不用8 (或可能的其他体系结构相关值)来写此检查将是一个令人惊讶的结果。
我想请求更新memory. c代码以显式处理__SYSMEM_size为0,链接程序也相应地进行了更新。
如果此请求未获批准,我希望请求相应地将此链接器行为记录在minit()源代码本身以及TI手册中。
--谢谢
您在尝试使用--heap_size=0时启动了三个不同的线程,尽管它们与malloc函数的问题有关。 我在SDOWP系统中提交了一个条目,以解决所有这些问题。 ID是 CodeGen-2112。 欢迎您使用我签名中下面的SDOWP链接进行关注。 该条目并不表示malloc函数中存在错误。 相反,它请求进行更改,以便在处理--heap_size=0的情况时使实现更可靠和更清楚。
谢谢,此致,
-George
感谢您跟进我的问题。
我理解这三个问题是相互关联的,如果您能更轻松地将它们组合到一个追踪编号下,那就足够公平了。
不过,简单地说,在处理malloc()时有一个错误,它确实在合理的使用情况下破坏了内存。
虽然我的偏好当然是处理我所有三个不同(但相关)的问题, 如果内存损坏错误在您的系统中被标记为增强功能而不是缺陷,因此长时间未修复,那将是一种耻辱。
此外,还有一个部分可能不清楚我在链接时确认没有使用堆的请求:
https://e2e.ti.com/support/development_tools/compiler/f/343/t/57.9456万
此请求是_NOT,用于在链接时检查堆大小是否已指定为0。 此请求允许在存在任何代码可能试图使用堆时阻止代码链接。 (因此,即使指定了大于0的堆大小,我也会期望它无法编译。) 同样,这是Keil ARM工具链提供的一种功能。
--谢谢
请放心,我将向编译器开发团队报告您的所有问题。 尽管存在各种增强功能和错误,但我仍然认为,一次展示所有这些功能是合理的。
为公平起见,我应该指出你的处境中的一个缺点。 在确定优先级时,我们(主要)考虑两个因素:实施的简便性和受益的客户数量。 理想的功能可以在一天内实现,并使我们的所有客户受益。 您的请求在这两方面都有问题。 它们的实施并不容易,而且请求这些更改的客户数量很少。
谢谢,此致,
-George