i.mx93 RT Core possible linker script issue

[albi84]

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:

1. Build the unmodified example and check the memory layout using the IMAGE INFO
   
2. 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);

       }

   }
3. Rebuild and inspect the map file / memory usage
   
4. 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?

[Zhiming_Liu]

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

[albi84]

One more thing: the RT core image is loaded via remoteproc on Linux.