[参考译文] CCS/AM3352：CCS 7.1 调试器尝试将使用GCC ARM编译器编译的AM3352引导加载程序加载到错误的内存地址

使用在 Ubuntu 16.04 LTS下运行的CCS 7.1 ．0.0.0016万 尝试在 AM3352的Cortex-A8上调试引导加载程序，在此应加载引导加载程序并从 0x402F0400在"SRAM internal"区域中运行。  0x402FFFFFFF。 bootloader使用 gcc-arm-none-eabi-4_9-2015q3编译器编译。

我将该项目恢复为使用TI ARM 5.2 16.04 6编译器和 运行 在Ubuntu 7.1 LTS下的CCS ELF. 0.0.0016万 编译，然后能够成功下载和调试bootloader.out文件。

 由gcc-arm-none-eabi-4_9-2015q3编译器编译的bootloader是有效的程序，因为如果将生成的二进制MLO文件复制到SD卡，则会由AM3352引导ROM成功运行bootloader。 问题在于  ，CCS 7.1 ．0.0.0016万 调试程序无法将gcc-arm-none-eabi-4_9-2015q3编译器生成的ELF bootloader.out文件成功下载到RAM中。

相同的目标硬件Blackhawk USB560-M仿真器，目标配置文件和GEL文件用于成功下载TI ARM编译器生成的程序，而不成功下载GCC ARM编译器生成的程序。

[QUEOTE USER="Johns (报价用户名)]我可以在 AM3359 BeagleBone上再现此内容。 我们需要深入了解符号信息，找出加载地址为0x402F0074的CCS原因。我使用Ubuntu readelf实用程序查看GCC ARM编译器生成的bootloader.out文件的标题，CCS将尝试开始为其写入内存 在地址 0x402F0074处：

$ readelf -hls bootloader/bootloader.out
ELF标题：
magic：7F 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 00 00
级： ELF32
数据： 2的补码，小尾端
版： 1 (当前)
OS/ABI： UNIX - System V
ABI版本： 0
类型： Exec (可执行文件)
计算机： ARM
版本： 0x1
入口点地址： 0x402f0400
程序头开始： 52 (字节进入文件)
节标题的起始位置： 9.776万 (字节到文件)
标志： 0x500.0402万，版本5 EABI，硬浮点ABI，
此报头的大小<unknown>：
52 (字节)程序标头大小： 32 (字节)
程序头数： 2
部分标题的大小： 40 (字节)
节标题数： 21
节标题字符串表索引：18

节标题：
[nr]名称 类型 地址 Off Size ES Flg Lk Inf AL
[0](关闭尺寸ES Flg Lk Inf AL [0]) 空 0万00 0000000万000 0000000亿 0 0 0
[1].rsstire. 程序 402f4亿 000020 00 AX 0 0 4
[2].text 程序 402f4.2亿 008960 00 AX 0 0 8
[3].arm.exidx ARM_EXIDX 402f8d8.0008万 008d8000.0008万 00 Al 2 0 4
[4].data 程序 402f8d8.8008万 008d8800043c 00 WA 0 8
[5].bss 注 402f9200 0091c4 000888400.0888万 00 WA 0128
[6].heap 程序 402f9a900091 0091d0万 00 0 0 16
[7].stack 注 402f9a900091 0091c400.2万 00 a 0 0 16
[8].arm.attributes arm_attributes 0万 0091d0 00002f000002f 00 001
1[9].comment 程序 0万 0091ff 0.007万 01 MS 0 1
[10].ISR_Vector 程序 0万00 0092700.0009万270 0000502.7亿 00 0 0 16
[11].debug_info 程序 0万 0092c0 0059df00059df 00 0 0 1
[12].debug_Abbrev. 程序 0万 00ec9f 0010c2 00 0 0 1
[13].debug_aranges PROGBITS 0万 00fd610008a8 00 0 0 1
[14].debug_ranges 程序 0万00 0106090.001万609 0007a860.9万7a8 00 0 0 1
[15].debug_line 程序 0万00 010db10.001万db1 002e601002e60 00 0 0 1
[16].debug_str 程序 0万00 013c110.0013万c11 0021151100.2115万 01 MS 0 1
[17].debug_frame 程序 0万00 015d280.0015万d28 001fe82.8001万fe8 00 0 0 4
[18].shstrtab STRTAB 0万00 017d100.0017万d10 0000cd00000cd 00 0 0 1
[19].symtab 符号 0万00 0181280.0018万128 0022801.2800228亿 10. 2.0363万 4
[20].strtab STRTAB 0万 01a3a80013d8 00 01
标志的关键字：
W (写入)，A (分配)，X (执行)，M (合并)，S (字符串)
I (信息)，L (链接顺序)，G (组)，T (TLS)，E (排除)， X (未知)
O (需要额外的操作系统处理) o (特定于操作系统)，p (特定于处理器)

程序标头：
类型 Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x008d80 0x402f8d80 0x402f8d80 0x0.0008万 0x0.0008万 R 0x4
加载 0x0万 0x402f0000 0x402f0000 0x091c4 0x0ba90 RWE 0x8000

段到段映射：
段段段...
00 arm.exidx
01 .rseride.text .arm.exidx .data .bss .stack 

装入程序头的对齐设置为0x8000 (32 KB)，要装入的节的ELF文件偏移的至少15位与装入地址的最不重要的15位匹配。 我认为这是一种优化，它允许ELF加载程序(在本例中为CCS调试程序)尝试将ELF文件中的连续字节数组直接写入程序内存。 ELF文件以一个52字节的标头和两个32字节的程序标头开始，总计52 +(2*32)=116=0x74，它与 CCS调试器尝试写入的地址0x402F0074中最不重要的15位匹配。 因为在AM3352上，地址范围为 0x402F0000。 0x402F03FF已保留且无法写入，这说明了将程序加载到内存中的"对齐优化"失败的原因。

通过添加选项"-z max-page-size=0x400"，GCC链接器已更改，以将加载程序标题的对齐从默认0x8000减少到0x400字节。 通过该更改，CCS 7.1 调试器可以成功地将bootloader.out文件加载到内存中。 添加max-page-size选项不会更改生成的二进制MLO文件，只会在ELF文件中加载Program Header，因为该文件阻止CCS调试器将bootloader.out文件加载到内存中。

不确定CCS调试器中决定如何将ELF文件内容加载到内存的加载程序是否应不受加载程序标头对齐导致尝试使用无法访问的内存的情况的影响。