[参考译文] PROCESSOR-SDK-AM335X：什么是 arm-none-eabi-objcopy.exe？ 为什么它会使输出膨胀？

您好 CSW、

TI 无法支持有关非 TI 编译器的问题。 您应该在这个 e2e 之外处理 GNU 问题。

我正在编译器团队中循环、以防有人知道您的任何输入。

我认为 GNU 编译器问题不应该在 TI 的 e2e 中得到解决。

谢谢

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output "]生成的 bin 文件为什么要大35倍？

除了确定外、所有这些都可以在已初始化的存储器范围之间有一个大漏洞。   这在二进制文件简介一文中进行了讨论。

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output 文件时 tiobj2bin.bat，它会调用 armhex.exe 和 mkhex4bin.exe [我 无法确定 哪个可执行文件进行转换...]

tiobj2bin.bat 是 Windows 批处理文件。  欢迎您使用您喜爱的文本编辑器检查它并了解它的工作原理。  虽然 CCS 随附、但它来自 代码生成工具 XML 处理实用程序。

请告诉我这些建议是否能解决问题。

谢谢、此致、

乔治

乔治

谢谢、但我不是这个初学者级别。  但是、我没有 ELF 布局或 链接器脚本的博士学位(尤其是加载了 SysBIOS 细节的自动生成脚本)

好的、我已经知道映像有责任包含一组不需要的内存：堆栈、堆等。

下一步...  如何删除它们？

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3762352 #3762352"] tiobj2bin.bat 是一个 Windows 批处理文件。

是的、我很久以前就深入到了这个脚本中、 这一点很难让人友好。  创建 bin 文件的是 armofd 还是 armhex？  我不知道，当然也找不到有用的文档  (令人惊讶的是、我收到了多少次回复"Duh…… 只需阅读本书。" 当我尝试的任何搜索都不显示"此"时)

但至少 EXE 似乎知道要丢弃什么以及要保留什么。  而无需外部标志的任何帮助。

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3762352 #3762352"] 这在二进制文件简介一文中进行了讨论。[/quot]

这是特定于 TI 的、TI 自己告诉我、他们不再支持 pdk_am335x_1_0_17。

链接器脚本自动生成的方式是... 谁知道...  因此、即使该文章有任何用途、我也无法控制该脚本中的任何内容。

因此、由于这是 TI 环境、TI 工具、TI 封装以及 TI 命名的段、调用 arm-none-eabi-objcopy 的脚本应该与其他脚本执行的操作相同。  (或项目属性中 GNU objcopy 实用程序设置中的默认值)

我发现了一些关于将-j .text 附加 标志添加到 arm-none-eabi-objcopy 命令以仅保留.text 段的注释。  好的、但我现在必须在链接器脚本中获得博士学位。

不是这个   software-dl.ti.com/.../sdto_cgt_Linker-Command-File-Primer.html

因为 TI 页面同样适用于 TI 特定的工具、 TI 自己告诉我、他们不再支持 pdk_am335x_1_0_17。

我发现在链接器脚本中定义了数十个段名、许多段名未使用。  它们是否都需要单独的标志？  哪些可以丢弃？  我知道可以删除.heap .bss .stack。  但是否必须保留其他内容？  其他所有内容都来自 SYSBIOS 库。  因此、即使是 GNU 文档也不会告诉我哪些 SYSBIOS 段会执行什么操作...

当这些段由 TI SYSBIOS/XDC 脚本生成时、"Go Ask GNU"这一注释几乎不是我要寻找的支持类型、我无法控制这些段、GNU 也不知道它们的含义。

－CSW

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3762492 #3762492"]因此我发现映像有责任包含一组不需要的内存：堆栈、堆等。

假设您删除了这些未初始化的段。  这样可以解决问题吗？  我不这么认为。  在彼此非常远的地址处初始化段的情况仍然存在。  二进制文件表示这些已初始化段之间的间隙的唯一方法是填充它们。   

实用程序在此二进制文件中读取什么内容？  它可以接受多个二进制文件吗？  还是只有一个？

谢谢、此致、

乔治

乔治

(另一个问题是转换后的项目(TI 17.3 -> GNUC 7.3)在加载 JTAG 时也不起作用。  跟踪调试器中的汇编器、它似乎与浮点数相关... 另一个我找不到的话题...  nano、vpflib、hard 等... 这将很快成为另一篇帖子...)

但关于这个。

当前工作的工程具有以下用于其映射文件的文件：

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
40300000    40300000    00001480   00000000    rw-
  40300000    40300000    00001480   00000000    rw- ocmc
80000000    80000000    00004000   00004000    r-x
  80000000    80000000    00000074   00000074    r-x .init
  80000074    80000074    00003f8c   00003f8c    r-x .text.1
80004000    80004000    008fa232   00000000    rw-
  80004000    80004000    008fa232   00000000    rw- .bss
808fe234    808fe234    0024b4ac   0024b4ac    r-x
  808fe234    808fe234    0024b4ac   0024b4ac    r-x .text.2
80b496e0    80b496e0    0004ea68   00000000    rw-
  80b496e0    80b496e0    0004ea68   00000000    rw- .data
80b98148    80b98148    0004a134   0004a134    r--
  80b98148    80b98148    0004a134   0004a134    r-- .const
80be227c    80be227c    00010000   00000000    rw-
  80be227c    80be227c    00010000   00000000    rw- .stack
80bf227c    80bf227c    000000fc   000000fc    r--
  80bf227c    80bf227c    000000fc   000000fc    r-- .init_array
80bf2400    80bf2400    00000040   00000040    r--
  80bf2400    80bf2400    00000040   00000040    r-- .vecs
80bf4000    80bf4000    00004000   00000000    rw-
  80bf4000    80bf4000    00004000   00000000    rw- ti.sysbios.family.arm.a8.mmuTableSection
80bf8000    80bf8000    00036b78   00036b78    r--
  80bf8000    80bf8000    00036b78   00036b78    r-- .cinit

是的、有孔洞...

我进行了数学计算、做了这些笔记、并将其与 JTAG 负载屏幕进行了比较。

TEXT1 16,268 (SHA512.obj x3f34 (16180) + TraceInterface.obj x58 (88) ) = 16,268 Unseen in load (too fast?)
BSS HOLE: 9,413,170
TEXT2 2,405,548 ( All remaining code - Seen loading image #1 )
DATA 322,152 ( Says UNINITIALIZED Would be a hole )
CONST 303,412 ( Hardcoded data -  Seen loading .data image #2 )
STACK 252 ( UNINITIALIZED Would be a hole )
INIT_ARRAY 64 ( has constructors - Unseen )
VECS 64 ( has VECS from app_pea8fnv.oea8fnv - Unseen )
MMUTABLE 16,384 ( UNINITIALIZED Would be a hole )
CINIT 224,120 ( handler table, BSS and OCMC load, and cinit table - Seen loading .data image #3 )

以及三个匹配的图像、其中负载的大小与条目匹配。

我必须假设其他负载的发生速度如此之快、以至于我看不到它们。  并跳过未初始化的块。   没有已加载内容的日志、只有窗口弹出并消失...

这与文本1匹配：

这与常量值匹配：

这与 CINIT 表相匹配

此外、当我将所有这些相加时、它会累加到最高12.3Meg、比实际的 bin 文件小约400K。  我不知道另一个400K 是什么。  所以... 在旧版本中、这种方法是合理的。 但我只接受它、因为我的目标是退出 TI 编译器。

使用 GNU 编译器进行的新编译不会给我提供一个很好的摘要、我可以找到它。  这不是 TI 的错。  但段名和位置由 TI 控制、因为链接器脚本由 TI 软件包生成。

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3762925 #3762925">该二进制文件中包含哪些实用程序？  它可以接受多个二进制文件吗？  [/报价]

对此、我们不想更改引导加载程序。 这将是数十万器件不得不更新的一个严重问题、因为核心固件更改了编译器。

(现有的过程是使用 ZIP 例程压缩此 bin、将其汇编到包含大量其他资源的文件中、并将其存储。  引导加载程序查找固件组件、将其解压缩、并从地址0x8000 0000...  解压缩现有的12M 文件不是问题。  解压缩1 gig 文件不是问题...)

现在... 将我学到的这些新东西与 GNU 编译器进行比较、我宁愿将这些东西拔出。  大多数人都有总数、但有些人(如普通人)没有、我不得不计算它。

ocmc				5248	(base address in bootloader)
mmuTableSection		16384
xdc.meta			278
.text				2825468
.init_array			64
.rodata				356269
.vectors			64
.ARM.extab			26456
.ARM.exidx 			21192
.data				270032
.bss				9629072
COMMON				4945032		
.stack				65536
			TOTAL SO FAR  -->  18,161,095
.stab				228			(base address  0?? )
.comment			380			(base address  0?? )
.ARM.attributes		59			(base address  0?? )
.debug_aranges		40984		(base address 0??)
.debug_info			19119579	(base address 0??)
.debug_abbrev		710246		(base address 0??)
.debug_line			1561500		(base address 0??)
.debug_frame		368984		(base address 0??)
.debug_str 			1889550
.debug_loc			2008064
.debug_ranges		150016
				TOTAL 44,010,685

您可以看到.bss 和.stack 放置在末尾很方便、这很有帮助。

总共为18Meg。。  但还有其他部分、我不知道它们是什么。  但我可以添加它们的长度、即使对于那些没有地址的其他段、它也不会累加1 gig。

那么、这就是我现在的位置...  想知道为什么一个 30、472、632字节(合理)的*。out 文件 应该根据 映射文件报告在内存中创建一个18、161、095 (同样合理)的映像、 由于 arm-no-eabi-objcopy.exe、最终结果是1、074、129、200？

我找不到任何让它假设它需要1 gig 内存的信息。  而示例"闪烁"项目认为它不需要1 gig。  CCS 环境项目设置中有一些对其进行控制的内容。  某处...

不要太专注于段的大小。  专注于他们在记忆中的位置。  考虑以下情况：二进制文件的大小由...给出。

(最高初始化段的结束地址+ 1)-最低初始化段的起始地址

• 最高初始化段-最高地址处的初始化段
• 最低初始化段-位于最低地址的初始化段

因此、为了减小二进制文件的大小、请使所有初始化段在存储器中彼此接近。

这需要更改链接器脚本。  您的链接器脚本来自何处？  如果是来自软件开发套件(SDK)、请提供名称和版本。  这可能允许我将此主题重定向到提供该主题的团队。

谢谢、此致、

乔治

乔治

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3764547 #3764547"]

二进制文件的大小由...给出。

(最高初始化段的结束地址+ 1)-最低初始化段的起始地址

• 最高初始化段-最高地址处的初始化段
• 最低初始化段-位于最低地址的初始化段

[/报价]

好的！  大约2小时前我发现了这个问题。 添加了 OCMC 部分添加了额外的1.07 gig... 仅在 GNU 工具集中。

CFG 文件具有以下内容：

Program.sectMap["ocmc"] = new Program.SectionSpec();
Program.sectMap["ocmc"].loadSegment = "OCMC_SRAM";

它在链接器脚本中生成了一个空的 OCMC 段。  这两者都是。

具体而言、这是根据 CFG 文件包括/排除的：

部分｛

ocmc：{*(ocmc)} at>OCMC_SRAM
vecs：{*(.vecs)} at>DDR3
TI.sysbios.family.arm.a8.mutableSection (NoLoad)：{*(ti.sysbios.family.arm.a8.mutableSection)} at>DDR3
xdc.meta (副本)：{keep(*)(Xdc.meta)} at>DDR3

(该项目的原始作者早已开始...  没有人能解释为什么包含此内容... 它是引导加载程序2代码部分。  我不知道这里是否需要它。 以及"模块"、"封装"、"工具"、它定义了"程序"...  我找不到任何支持文档)

这会返回到一些创建链接器脚本的隐藏工具、我猜来自 CFG 文件、谁知道其他什么。 我知道其中一些来自"平台"文件。

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3764547 #3764547"]链接器脚本来自哪里？

它来自哪里？  该项目的"平台"是 ti.platforms.evmAM3359。  这是我尝试转换的大项目、也是我在原始帖子中提到的小示例项目。

我不知道是什么造成的。  它由 CCS 工具生成。  它甚至有一个免责声明、说不要修改它、因为它将被覆盖。

但是、很显然、无论构建哪个链接器脚本、它都会从 CFG 文件中获取一些它正在进行的标识。

我知道 C：\TI 文件夹中的"平台"设置中有一些内容。

如果我必须进入并破解 C：\TI\XDC 或 C：\TI\SYSBIOS 文件夹中的一些设置文件脚本、那么它在某种程度上会使在项目中获取所有必要文件并将其提交到任何源代码控制中的功能失败、不是吗？

这是另一个无法理解的典型示例。

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3764547 #3764547"]如果它来自软件开发套件(SDK)，请提供名称和版本

我看到我没有将其包括在这个帖子中。  抱歉。  (我有几篇公开文章试图解答人们似乎无法解释的问题)。 这是 pdk_am335x_1_0_17、并在  CCS 1011上使用 BIOS_6_76_03_01和 xdctools_3_55_02_22_core。

为什么 TI 工具 armofd 或 armhex 不会在输出中放置该额外的孔、而 GNU arm-no-eabi-objcopy 会这样做？  它怎么知道不这样做？

最后、相同的 CFG 会生成几乎相同的链接器脚本、然后 TI 的 armofd 或 armhex 会正确忽略空的 OCMC 部分(我说是正确的、因为它为我提供 了正确的 bin 文件... 但可能已经损坏)。  但是出于某种原因、GNU 版本为我提供了不同的 bin 文件、而不是省略 OCMC 部分。

我无法使用#ifdef __GNU__之类的内容从 CFG 文件中省略该部分。  TI 和 GNU 两种配置都需要能够成功构建。  有一个可支持的安装基础。

那么、这将变得越来越近。

下面是一张粗略的草图、说明我认为您应该尝试下一个步骤。

下面是 CFG 文件中影响链接器脚本的一些文档。  重点介绍名为  struct Program.SectionSpec 的器件。  使用它可以更改段如何分配给存储器。  有哪些变化？  请参阅使用 TI ARM 编译器构建的工程中的链接器命令文件。  链接器命令文件以使初始化的段彼此接近的方式将段分配到存储器。  这就是您需要实现的目标。

谢谢、此致、

乔治

乔治

是的、正如我在上一个帖子中所说、 SecectionSpec 已从 CFG 文件中删除、并且 bin 现在更小、因为它不必从 OCMC 存储器加载...  但现在它可能太小(如下面的#3所示)。

我还有其他一些事情需要我先解决。  但这一切都可能是相关的，我不知道。  因为每次我想我解决问题1时、后面都会弹出两个问题。

当我使用 CCS 直接通过 JTAG (XDS100v2)调试器加载*。out 文件时、该应用程序不起作用。

1. 单步执行代码、它会初始化一些结构... 但是、调试器正在向我展示存储器中这些地址的地址、它们正在发生冲突！  我不知道为什么结构"A"的基址位于结构"b"的中间。  链接器应该能够处理该问题。
2. 我注意到、当我使用 CCS 调试器和 JTAG 加载*。out 文件时、我从未看到它说它是"加载.data"。  它只显示为"loading .text"。 然而、我们知道代码中有很多初始化的.data、来自同一项目的 TI 编译。
   
   这与我运行完全相同编译代码的 TI 编译时不同(正如我之前的文章所示、.text 和.data 的单独弹出窗口)。
   
   
3. 最后、映射文件会在一个名为"common (通用)"的部分中向我展示大量内容。  更具体地说、更多的静态/全局变量可以放入最终的二进制文件中。  因此、我不知道链接器对这些变量执行了什么操作、它们似乎不是通过上面第2步所述的调试会话加载的)、或者它们是否在转换为 bin 映像时丢失了。

当然、这是一个"示例"、但当您必须整合一个真实的大型计划时、这是非常令人沮丧的。

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3766310 #3766310"]我不知道结构"a"为什么具有位于结构"b"中间的基址。[/quot]

结构 b 可能包含结构 a 作为成员。  我怀疑这是一个实际的问题。 如果是、则在编译或链接时会出现问题。

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3766310 #3766310"]我注意到、当我使用 CCS 调试器和 JTAG 加载*。out 文件时、我从未看到它说是"加载.data"。

我怀疑这是一个令人关注的问题。  了解如何将段分配给内存。  使用 CCS Feature View | Memory Allocation 或查看链接器映射文件。  

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3766310 #3766310"]地图文件在一个名为"common "的部分中向我展示了许多内容

这是一个与.bss 类似的未初始化段。 与所有其他未初始化的段一样、创建二进制文件时会忽略它。  但它可能会导致意外的间隙。

谢谢、此致、

乔治

乔治

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3767417 #3767417"]Maybe struct b 包含结构 A 作为成员。  我怀疑这是一个实际的问题。 如果是、您在编译或链接时会遇到问题。

看起来是源代码"A"在不打包的情况下编译了头文件、而源代码"B"则是打包的。  (这些是全局机器状态结构)

因此、模块 A 会更新该结构中的某个内容、但就模块 B 而言、存储器是另一个位置。

这里有大量的结构、几乎有数百个打包 pragma ...  编译器警告说、字节、字符等不需要打包 pragma。  它会使项目爆炸并显示警告、TI 编译器会忽略这些警告。

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3767417 #3767417">使用 CCS 功能视图|存储器分配、或查看链接器映射文件。  [/报价]

我一直在不断地探索链接器文件、以找到这些部分、并弄清哪个模块具有 一些内容。

[引用 userid="4373 " URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3767417 #3767417"]

克里斯托弗·韦伯说：

我注意到、当我使用 CCS 调试器和 JTAG 加载*。out 文件时、我从未看到它说它是"加载.data"。

我怀疑这是一个令人关注的问题。  

[/报价]

我不得不找出...  您是正确的、这不是问题。  我获取了一个示例程序、并加载了大量硬编码全局数据。  在 TI 编译中、JTAG 加载过程显示了针对.text 和.data 的单独步骤。  在 GNU 编译中、它是一个包含数据的大型.text 加载。

JTAG 加载窗口显示.text、但这是错误的。  它实际上是.text 和.data。  也存在任何空穴。

我还将巨型块从 unsigned char 更改为 const unsigned char、映射文件显示该段从.data 更改为.rodata。  但负载的大小没有变化。 bin 文件也没有。

我注意到 JTAG 加载窗口显示的字节大小与 bin 文件大小相同。

这会打开另一个问题(不是问题、只是需要理解)。  当在编译后处理步骤中未创建 bin 文件时(我删除了该步骤并删除了 bin 文件)、JTAG 加载过程仍显示加载 的图像大小与以前的 bin 相同...  它是如何创建它的？  它不是我可以在文件系统上找到的任何位置。

正在取得进展...

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3767487 #3767487"]如果未在编译后处理步骤中创建 bin 文件(我删除了该步骤并删除了 bin 文件)、JTAG 加载过程仍会显示加载 大小与 bin 相同的映像...  它是如何创建它的？[/quot]

CCS 通常加载由链接器创建的.out 文件。  该文件通常与 CCS 工程具有相同的名称、文件扩展名为.out。

谢谢、此致、

乔治

乔治

这是不正确的。  我的*。out 文件为2、851K。  bin 文件为1、469 K

根据文件属性、该值恰好为1、504、128字节。

调试加载与 bin 文件加载完全匹配。   因此它不能是十六进制文件。

然而、即使我删除 bin 文件并禁用其创建、CCS 也会执行此加载。

那么、CCS 调试器将其转换/分段到存储器映像的确切位置/方式是什么？

因为使用  arm-none-eabi-objcopy.exe 的设置会将文件写回文件系统、而不是这样。

CCS 使用其他一些工具来实现它。

[引用 userid="47996" URL"~/support/processors-group/processors/f/processors-forum/1017744/processor-sdk-am335x-what-is-arm-none-eabi-objcopy-exe-why-is-it-bloating-the-output/3776799 #3776799"] CCS 调试器在何处/如何将其转换/分拆为内存映像[/quot]

CCS 具有一个内置加载程序、可理解.out 文件的格式。  它知道如何将代码和数据直接从该文件复制到系统中适当的存储器范围中。

谢谢、此致、

乔治