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.

Linker not following section ordering per command file

I have the following linker command file:

MEMORY
{
   shared_ram:      ORIGIN = 0x40200000  LENGTH = 0x00010000
}

SECTIONS
{
   .text: align=4
   {
           mmcload.obj(.text)
           *(.text)
   } > shared_ram
  
   .const: align=4   { *(.const) }   > shared_ram
   .data: align=4    { *(.data)  }   > shared_ram
  
   .bss: align=4
   {
          _bss_start = .;
          *(.bss)
          _bss_end = .;
  
   } > shared_ram
}

When I look at the mapfile, this is what I see:

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
40200000    40200000    0000ae54   0000ae54    r-x
  40200000    40200000    0000ae54   0000ae54    r-x .text
4020ae54    4020ae54    0000086a   00000000    rw-
  4020ae54    4020ae54    0000086a   00000000    rw- .bss
4020b6c0    4020b6c0    00000439   00000439    r--
  4020b6c0    4020b6c0    00000439   00000439    r-- .const
4020bafc    4020bafc    00000858   00000055    rw-
  4020bafc    4020bafc    00000055   00000055    rw- .data
  4020bb54    4020bb54    00000800   00000000    rw- .stack

Undoubtedly, you will notice that the order of the output sections given in the linker command file:

.text

.const

.data

.bss

is not being followed, because the mapfile shows them as being in the order of:

.text

.bss

.const

.data

FURTHERMORE

your documentation (spnu118i.pdf, page 188) states:

The SECTIONS directive controls your sections in the following ways:
• Describes how input sections are combined into output sections
• Defines output sections in the executable program
Specifies where output sections are placed in memory (in relation to each other and to the entire
memory space)

• Permits renaming of output sections

Well, it's clearly not doing this.

I'm REALLY tired of dealing with these tools.

Can someone explain this irrational and (according to your documentation) incorrect behavior?

Incidentally, the workaround is to do

.text

{

mmcload.obj(.text)

*(.text)
*(.const)

*(.data)

}

 

but I don't want to.

I want the tools to behave the way they're documented!!

I need this ordering because I'm going to convert this to binary for putting into an MLO file to put onto an SD card to boot my system.

I eagerly await someone's prompt reply.  I'm hoping I'll get one w/in 24 hours.