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.

[参考译文] TDA2xx A15&GNU 工具

Guru**** 2044370 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/669294/tda2xx-a15-gnu-tools

您好!

由于 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 段、因此应将它们抛出、在这种情况下、映射文件为什么仍会列出它们(不在已丢弃的段下、而是在常规已分配的段部分下)。

谢谢

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    大家好、

    由于这些是 GCC 和 ARM 特有的问题、我需要花一些时间来浏览文档。 我将在星期五之前向您回复我的调查结果。

    谢谢、此致、
    Piyali
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、

    对拖延答复表示歉意。 我们正在尝试在您的问题上获得编译器团队的帮助。

    谢谢、此致、

    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 组织发布一个问题。  他们是发布此编译器的人。  我以前从未提出过问题。  这意味着我第一次可能会犯错。  请耐心等待。  此外、您提出此类问题的地方不是像这个这样的公共论坛。  因此、我无法让您看到该对话。

    谢谢、此致、

    乔治

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    谢谢、
    感谢您尝试寻找答案。
    同时、根据您所写的内容、这是否意味着我必须查看链接器示例文件、并确保我的命令文件上具有适当的上述所有符号(由于无法正确分配这些符号、我无法按原样使用该文件)。 我假设这些符号中的大多数仅对非常具体的用法很重要、 我可能不需要什么-例如、当您说.arm.exidx 是 C++异常处理表的指示符时-因为我不使用 C++、我猜这对我来说是"无关"-我是对的吗? 这些符号的其余部分如何-您将在私人表单上查找的部分答案是什么?
    我查看了示例链接器脚本、但我仍然不确定何时何地需要这些脚本-有注释、但我没有上下文或它假定的存储器映射类型...

    谢谢
    家伙
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    请记住、我在第一个帖子中显示的链接器脚本代码只是一个示例。  您需要准确确定您的编译使用的链接器脚本、并对其进行检查。

    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。"

    谢谢、此致、

    乔治

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!
    非常感谢您为获得答案所做的努力。
    您是否可以提供这些"例外索引表段"的简单示例、以说明用法和行为并尝试使其更清晰?

    谢谢
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    异常处理表是有关这些函数中的函数和对象的特殊编码信息、在传播 C++异常时需要考虑这些函数和对象。 它们由 RTS 中的特殊函数读取、并不意味着用户可以直接读取。 有关文档、请参阅 infocenter.arm.com/.../IHI0038B_ehabi.pdf