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 编译器当前与 A15内核不兼容、 因此它使用的工具链是基于 GNU 的工具链。
在编译 A15时、工具链对一些符号有一些假设、似乎需要正确设置它们。
例如、end 符号应指示堆的开始、并假设堆栈段紧随其后(在堆之后)。
我注意到在映射文件中有一个名为 .arm.exidx 的段,有人能简单地解释一下这是什么,如果需要考虑到对其位置的任何假设吗?
我是否应该注意并注意内核/工具链的任何其他特殊符号(从链接器的角度来看,在列表中-内存分配以确保它们不会导致内存损坏)?
我还看到了我的映射文件
arm.exidx 0x4032428 0x8
arm.exidx 0x40324028 0x8 C:/..../gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu libgcc.A (_divdi3.o)
arm.exidx 0x4032430 0x0 C:/..../gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu/libgcc.a (_divdi3.o)
0x8 (放松前的大小)
您能否解释一下在放松之前它的尺寸是什么意思? 它实际上是否占用内存空间?
我还看到过零大小的部分,在本例中,为什么它们显示在地图文件上-我使用- GC 段、因此应将它们抛出、在这种情况下、映射文件为什么仍会列出它们(不在已丢弃的段下、而是在常规已分配的段部分下)。
谢谢
大家好、
对拖延答复表示歉意。 我们正在尝试在您的问题上获得编译器团队的帮助。
谢谢、此致、
Piyali
我可以给一些光亮。 但我无法回答你的所有问题。
[引用 user="Guy Mardiks"]
在编译 A15时、工具链对一些符号有一些假设、似乎需要正确设置它们。
例如、end 符号应指示堆的开始、并假设堆栈段紧随其后(在堆之后)。
[/报价]
您应该会在链接器脚本中看到所有这些内容。 假设您使用 Code Composer Studio 附带的 Linaro ARM GCC 编译器。 编译器的基址是一个类似于...的位置。
C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-4_9-2015q3
位置 共享\gcc-arm-none-eabi\samples 中有一些基本示例。 进入其中一个、通过运行"gmake -n"来查看其编译命令。 L 选项显示链接器脚本的位置、而-T 选项指定链接器脚本的名称。 文件扩展名通常为.ld。 检查该文件。 你会看到这样的评论...
用于放置段和符号值的//链接器脚本。 应* 与定义存储器区域闪存和 RAM 的其他链接器脚本一起使用。 *它引用了以下符号,这些符号必须在代码中定义: * Reset_Handler:输入复位处理程序 * 它定义了以下符号,可以在没有定义的情况下使用哪些代码: *__exidx_start *__exidx_end *__copy_table_start__ *__copy_table_end__ *__zero_table_start__ *__zero_table_end__ *__etext *__data_start__ *__init_preack_array_start_st_stack_end___ *____*__*__*__
在该文件中搜索名为 end 的符号、以查看其定义方式。 这些是我检查的链接器脚本的最后一行...
堆(副本): { __end__=.; 提供(end =.); *(.heap*) __HeapLimit=.; }> RAM /*.stack_dummy 段不包含任何符号。 链接器仅*用于计算栈段的大小、 并在稍后将*值分配给栈符号*。 stack_dummy (copy): { *(.stack*) }> RAM /*将堆栈顶部设置为 RAM 的末尾、堆栈限制向下移动* stack_dummy section 的大小*/ __ StackTop = origin (RAM)+ length (RAM); __ StackLimit =__ StackTop - SIZEOF (.stack_dummy); Provide (_ stack_stack_stack =_ Stack_top); /*检查数据+堆+堆栈是否超出 RAM 限制*/ assert (__StackLimit>=__HeapLimit,“区域 RAM 溢出堆栈”) }
正如您说过的、符号 end 标记堆的开始、堆栈位于堆之后。
[引用 user="Guy Mardiks"]我在地图文件中注意到有一个名为 .arm.exidx 的段,有人能否简单地解释一下这是什么[/引用]
C++异常处理表。 我检查过的链接器脚本会将其放入闪存存储器区域。
关于您的其他问题... 我有一些猜测、但我不知道。 我将向 Linaro 组织发布一个问题。 他们是发布此编译器的人。 我以前从未提出过问题。 这意味着我第一次可能会犯错。 请耐心等待。 此外、您提出此类问题的地方不是像这个这样的公共论坛。 因此、我无法让您看到该对话。
谢谢、此致、
乔治
请记住、我在第一个帖子中显示的链接器脚本代码只是一个示例。 您需要准确确定您的编译使用的链接器脚本、并对其进行检查。
Guy Mardiks 说:这是否意味着我必须查看链接器示例文件、并确保我具有上述所有符号、均已正确定位
否 在我显示的链接器脚本中、唯一需要的符号是 Reset_Handler。 该符号在启动代码中定义、而不是在用户代码中定义。 其余符号在链接器脚本中定义。 如果需要、用户代码可以引用这些符号、但这不是必需的。
[引用 user="Guy Mardiks"]当您说.arm.exidx 是 C++异常处理表的指示符时-由于我不使用 C++、我猜这对我来说是"无关"-我对吗?
是的。 在您的情况下、此部分为空。
[引用 user="Guy Mardiks"]我查看了示例链接器脚本,但我仍不确定何时何地实际需要这些脚本
链接器文档包括链接器脚本中语法的说明,可在 PDF 文件中找到,其位置类似于...。
C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\share\doc\gcc-arm-no-eabi\pdf\ld.pdf
谢谢、此致、
乔治
关于.
[引用 user="Guy Mardiks"]
我还看到了我的映射文件
arm.exidx 0x4032428 0x8
arm.exidx 0x40324028 0x8 C:/..../gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu libgcc.A (_divdi3.o)
arm.exidx 0x4032430 0x0 C:/..../gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu/libgcc.a (_divdi3.o)
0x8 (放松前的大小)
您能否解释一下在放松之前它的尺寸是什么意思? 它实际上是否占用内存空间?
[/报价]
以下是 Linaro 专家的回答...
".arM.exidx 段是异常索引表段、我可以最简要地解释这些是用于释放信息的函数地址映射表。 此表按升序函数地址排序、并设计为可合并具有相同条目的连续条目。 例如、用于不带解压信息的函数的特殊条目 EXIDX_CANTUNWIND 非常常见、因此这可以节省相当大的空间。
在链接时、更改了大小的段通常被描述为"宽松"。 因此、在这种情况下、宽松的大小只是删除了重复项后的大小。
可以在 EHABI http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf 中找到更多有关异常处理的文档 、但这仅提及可以删除重复的.arM.exidx 表条目。"
谢谢、此致、
乔治
关于.
[引用 user="Guy Mardiks">我还看到过零大小的部分,在本例中,为什么它们显示在地图文件上-我使用-- GC 段、因此应将它们抛出、在这种情况下、映射文件为什么仍会列出它们(不在已丢弃的段下、而是在常规已分配的段段部分下)。
以下是 Linaro 专家的回答...
"一个可能的原因是、0大小的段定义了程序的另一部分引用的符号。 -gc 段会删除不会从入口点重定位到的段、但不会考虑它们的大小。 例如:
.text
.globl _start
_start:BX lr
.word 为空
.section ".text.1"、"ax"、%progbits"
.globl 为空
空:
.section ".text.2"、"ax"、%progbits"
globl empty2
空2:
arm-linux-gnueabihf-gcc -c file.s
arm-linux-gnueabihf-ld file.o --gc-sections --print-map
这应该表明.text.2被.text.1丢弃在映射文件中、且大小为0。"
谢谢、此致、
乔治