i.mx93 RT Core possible linker script issue Hi, I may have found an issue in the RT core linker script / memory layout used in the SDK, and I would like to check whether I am misunderstanding something or whether this is indeed a bug. Development environment VS Code 1.111.0 MCUXpresso for VS Code extension 26.2.46 SDK 25.09.00 In the linker scripts, the .data section is defined as a section that is copied from program memory to working memory at startup, which is fine and expected. In other words, .data is placed into RAM at runtime, while its initialization values are stored in program memory, using something like: .data : AT(__DATA_ROM) { ... } > m_data My concern is about what happens after that. As I understand GNU ld behavior, once an output section gets a load address via AT(...), the following allocatable sections in the same memory region may inherit a related LMA handling unless explicitly separated or marked otherwise. In this case, it appears that subsequent sections such as .bss, .heap, and .stack also end up reserving space in m_text / program memory, even though they should not require ROM initialization data. This seems problematic because: .bss should normally only occupy RAM and be zero-initialized by the startup code .heap and .stack should also only reserve RAM space none of these sections should consume additional space in program memory I can reproduce the behavior very easily with the standard Hello World example: Build the unmodified example and check the memory layout using the IMAGE INFO Add a large uninitialized global array, for example: /*! * @brief Task responsible for printing of "Hello world." message. */ volatile uint32_t test_array[10240]; /* 40KB array */ static void hello_task(void *pvParameters) { (void)test_array[0]; /* prevent optimization */ for (;;) { PRINTF("Hello world.\r\n"); vTaskSuspend(NULL); } } Rebuild and inspect the map file / memory usage It appears that increasing the size of this uninitialized object also increases the usage of m_text / program memory, as if .bss-type content were being accounted for there as well My expectation would be that only .data consumes ROM image space, while .bss, .heap, and .stack only consume RAM. Newer SDK does not solve this problem. Adding (NOLOAD) attributes to sections also does not solve the problem. Reordering the sections in m_data memory (for example moving the .bss before .data) resolves some of the issues but moving .heap and .stack introduces some other. So my question is: Am I missing something in how this linker script is intended to work, or is this a bug in the SDK linker layout? Re: i.mx93 RT Core possible linker script issue Hi @albi84
It appears to be a display issue with the "image info" tool. If you use readelf to compare the before and after versions, the .data section hasn't grown, while the .bss section has clearly expanded, but .bss is marked as NOBITS. The file offset "Off" is the same for all NOBITS segments.
Original:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interrupts PROGBITS 0ffe0000 001000 000474 00 A 0 0 4
[ 2] .resource_table PROGBITS 0ffe0478 004044 000000 00 W 0 0 1
[ 3] .text PROGBITS 0ffe0478 001478 0028b4 00 AX 0 0 4
[ 4] .ARM ARM_EXIDX 0ffe2d2c 003d2c 000008 00 AL 3 0 4
[ 5] .init_array INIT_ARRAY 0ffe2d34 003d34 000004 04 WA 0 0 4
[ 6] .fini_array FINI_ARRAY 0ffe2d38 003d38 000004 04 WA 0 0 4
[ 7] .interrupts_ram PROGBITS 20003000 004044 000000 00 W 0 0 1
[ 8] .data PROGBITS 20003000 004000 000044 00 WA 0 0 4
[ 9] .bss NOBITS 20003044 004044 00007c 00 WA 0 0 4
[10] .m33_suspend PROGBITS 20000000 004044 000000 00 W 0 0 1
[11] .heap NOBITS 200030c0 004044 000400 00 WA 0 0 1
[12] .stack NOBITS 200034c0 004044 000400 00 WA 0 0 1
[13] .ARM.attributes ARM_ATTRIBUTES 00000000 004044 000036 00 0 0 1
[14] .debug_line_str PROGBITS 00000000 00407a 000373 01 MS 0 0 1
[15] .debug_info PROGBITS 00000000 0043ed 00a36c 00 0 0 1
[16] .debug_abbrev PROGBITS 00000000 00e759 00146b 00 0 0 1
[17] .debug_aranges PROGBITS 00000000 00fbc8 000498 00 0 0 8
[18] .debug_rnglists PROGBITS 00000000 010060 000326 00 0 0 1
[19] .debug_line PROGBITS 00000000 010386 003f34 00 0 0 1
[20] .debug_str PROGBITS 00000000 0142ba 0076f4 01 MS 0 0 1
[21] .comment PROGBITS 00000000 01b9ae 000045 01 MS 0 0 1
[22] .debug_frame PROGBITS 00000000 01b9f4 001230 00 0 0 4
[23] .symtab SYMTAB 00000000 01cc24 002d00 10 24 267 4
[24] .strtab STRTAB 00000000 01f924 002949 00 0 0 1
[25] .shstrtab STRTAB 00000000 02226d 000115 00 0 0 1
Add array
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interrupts PROGBITS 0ffe0000 001000 000474 00 A 0 0 4
[ 2] .resource_table PROGBITS 0ffe0478 004044 000000 00 W 0 0 1
[ 3] .text PROGBITS 0ffe0478 001478 0028b4 00 AX 0 0 4
[ 4] .ARM ARM_EXIDX 0ffe2d2c 003d2c 000008 00 AL 3 0 4
[ 5] .init_array INIT_ARRAY 0ffe2d34 003d34 000004 04 WA 0 0 4
[ 6] .fini_array FINI_ARRAY 0ffe2d38 003d38 000004 04 WA 0 0 4
[ 7] .interrupts_ram PROGBITS 20003000 004044 000000 00 W 0 0 1
[ 8] .data PROGBITS 20003000 004000 000044 00 WA 0 0 4
[ 9] .bss NOBITS 20003044 004044 00a07c 00 WA 0 0 4
[10] .m33_suspend PROGBITS 20000000 004044 000000 00 W 0 0 1
[11] .heap NOBITS 2000d0c0 004044 000400 00 WA 0 0 1
[12] .stack NOBITS 2000d4c0 004044 000400 00 WA 0 0 1
[13] .ARM.attributes ARM_ATTRIBUTES 00000000 004044 000036 00 0 0 1
[14] .debug_line_str PROGBITS 00000000 00407a 000373 01 MS 0 0 1
[15] .debug_info PROGBITS 00000000 0043ed 00a763 00 0 0 1
[16] .debug_abbrev PROGBITS 00000000 00eb50 0014c6 00 0 0 1
[17] .debug_aranges PROGBITS 00000000 010018 000498 00 0 0 8
[18] .debug_rnglists PROGBITS 00000000 0104b0 000326 00 0 0 1
[19] .debug_line PROGBITS 00000000 0107d6 0040d5 00 0 0 1
[20] .debug_str PROGBITS 00000000 0148ab 0076ff 01 MS 0 0 1
[21] .comment PROGBITS 00000000 01bfaa 000045 01 MS 0 0 1
[22] .debug_frame PROGBITS 00000000 01bff0 001230 00 0 0 4
[23] .symtab SYMTAB 00000000 01d220 002d20 10 24 268 4
[24] .strtab STRTAB 00000000 01ff40 002954 00 0 0 1
[25] .shstrtab STRTAB 00000000 022894 000115 00 0 0 1
Best Regards, Zhiming Re: i.mx93 RT Core possible linker script issue One more thing: the RT core image is loaded via remoteproc on Linux.
查看全文
