Linker - Location of named section

Tony Morrell

Hi,

Toolset 4.7.1, CCS 5.0.1.201012231000

In my Linker.cmd, I would like to locate one of my named sections at the very end of the image. I have to now done this by defining a memory region at the end of the image, and then locating my section within it. However, this is too restrictive, I would like to keep the final image size as small as possible for programming reasons, and would like this final section to be placed at the end of used image space, so that it will move up or down as my image size changes.

Current Implementation:

MEMORY

{
   HEADER (RX) : origin=0x00080000 length=0x00000008 fill=0xFFFFFFFF
   APP (RX) : origin=0x00080008 length=0x0003FEF8 fill=0xFFFFFFFF
   FOOTER (RX) : origin=0x000BFF00 length=0x00000100 fill=0xFFFFFFFF
}

SECTIONS
{
   .header : {} > HEADER
   .text : {} > APP
   .const : {} > APP
   .cinit : {} > APP
   .footer : {} > FOOTER
}

I understand from the ARM Assembly Language Tools v4.7 User's Guide (SPNU118I November 2010) that "By default, the linker begins at 0h and places the sections one after the other in the following order: .text, .const, .data, .bss, .cinit, and then any named sections in the order they are encountered in the input files." (section 2.3.1), so I tried the following solution (got rid of MEMORY FOOTER and direct .footer to MEMORY APP):

MEMORY

{
   HEADER (RX) : origin=0x00080000 length=0x00000008 fill=0xFFFFFFFF
   APP (RX) : origin=0x00080008 length=0x0003FFF8 fill=0xFFFFFFFF
}

SECTIONS
{
   .header : {} > HEADER
   .text : {} > APP
   .const : {} > APP
   .cinit : {} > APP
   .footer : {} > APP
}

My named section .footer should be located after the .cinit section. However, looking at my output map file, I can see that .cinit is the last section in my image:

SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members

---------- ----------- ---------- ----------- ----- -------

00080000 00080000 00040000 00040000 r-x

00080000 00080000 00000008 00000008 r-- .header

00080008 00080008 000116bc 000116bc r-x .text

000916c4 000916c4 00000004 00000004 r-- $fill000

000916c8 000916c8 000067d9 000067d9 r-- .const

00097ea1 00097ea1 00000003 00000003 r-- $fill001

00097ea4 00097ea4 00000100 00000100 r-- .footer

00097fa4 00097fa4 00000004 00000004 r-- $fill002

00097fa8 00097fa8 00000118 00000118 r-- .cinit

000980c0 000980c0 00027f40 00027f40 r-- $fill003

Does anybody have any suggestions about how to get my .footer section located at the very end of the image without defining a new MEMORY region?

As an aside, I'm getting the following warnings from the linker which are very annoying when trying to get a warning free build:

warning: section MvMotorControlTMS570.elf(.const) was padded by 3 to a size of 26588 to satisfy the specified memory width of 4

warning: section MvMotorControlTMS570.elf($fill001) at 097ea1h overlaps MvMotorControlTMS570.elf(.const) (MvMotorControlTMS570.elf($fill001) incomplete or skipped)

So, the linker has created fill section $fill001 between .const and .footer to get the alignment for .footer, and then complains that .const and $fill001 overlap!

Regards, Tony.

over 14 years ago

0 AartiG over 14 years ago

TI__Guru**** 173310 points

Tony,

Tony Morrell said:

My named section .footer should be located after the .cinit section. However, looking at my output map file, I can see that .cinit is the last section in my image:

Please take a look at this FAQ that explains the ordering of linker input and output sections. Using the GROUP directive as explained in that article should allow you to have better control over the order of sections, (ie) in making sure .footer is allocated last in the group.

0 Tony Morrell over 14 years ago in reply to AartiG

Genius 4130 points

Hi Aarti,

That has very neatly answered my question.

Any ideas about the linker warnings?

Regards, Tony.

0 Archaeologist over 14 years ago

TI__Guru* 84285 points

Tony Morrell said:

As an aside, I'm getting the following warnings from the linker which are very annoying when trying to get a warning free build:

warning: section MvMotorControlTMS570.elf(.const) was padded by 3 to a size of 26588 to satisfy the specified memory width of 4

warning: section MvMotorControlTMS570.elf($fill001) at 097ea1h overlaps MvMotorControlTMS570.elf(.const) (MvMotorControlTMS570.elf($fill001) incomplete or skipped)

So, the linker has created fill section $fill001 between .const and .footer to get the alignment for .footer, and then complains that .const and $fill001 overlap!

Those warning messages are from the hex conversion utility, not the linker. If you look carefully at the linker command file, .const does not overlap $fill001. Can you show us your hex converter command line arguments and hex converter command file?

0 George Mock over 14 years ago in reply to AartiG

TI__Guru**** 249640 points

Another altenative for allocating .footer at the highest address ... Consider using the high specifier. See the section titled Controlling Allocation Using The HIGH Location Specifier in the ARM assembly tools manual.

Thanks and regards,

-George

0 Tony Morrell over 14 years ago in reply to George Mock

Genius 4130 points

Georgem said:

Another altenative for allocating .footer at the highest address ... Consider using the high specifier. See the section titled Controlling Allocation Using The HIGH Location Specifier in the ARM assembly tools manual.

Hi George,

Thanks for looking at this, but it's not quite what I am after. I don't ant the .footer section at the high memory address, I need it to be located imediately following the other sections, but last of all. Aarti's suggestion of using the GROUP syntax has exactly done this.

Regards, Tony.

0 Tony Morrell over 14 years ago in reply to Archaeologist

Genius 4130 points

Archaeologist said:

Those warning messages are from the hex conversion utility, not the linker. If you look carefully at the linker command file, .const does not overlap $fill001. Can you show us your hex converter command line arguments and hex converter command file?

Hi Archaeologist,

I should have spotted that they are not linker errors. My hex converter invocation is:

"C:/Program Files/Texas Instruments/TMS470 Code Generation Tools 4.7.1/bin/hex470.exe" -i -romwidth=32 -o MvMotorControlTMS570.hex MvMotorControlTMS570.elf

As far as I'm aware, I don't have a hex converter command file. Is it a TI provided file with the toolset installation that is used by default. What filename extension would it have and how is it referenced on the command line? What should it look like for a TMS570?

Regard, Tony.

0 Tony Morrell over 14 years ago in reply to Tony Morrell

Genius 4130 points

Hi,

This is a new problem introduced by following Aarti's advice and reworking my Linker.cmd section definitions. I now have:

MEMORY

{
   APP (RX) : origin=0x00080000 length=0x00040000 fill=0xFFFFFFFF
   RAM (RW) : origin=0x08004000 length=0x00024000
}

SECTIONS
{
   GROUP
   {
   .header : {}
   .text : {}
   .const : {}
   .cinit : {}
   .footer : {}
   } > APP

   .bss : {} > RAM
   .data : {} > RAM
}

This gives me a linker warning which I don't get with my original configuration (see top of post, with same MEMORY RAM and .bss/.data):

warning #10229-D: output section ".data" refers to load symbol "Ctrl_HandleDisabledMode" and hence cannot be compressed; compression "rle" is ignored

Any ideas? I don't see how I've influenced the output to .data with my definition of the flash memory region.

Thanks, Tony.

0 AartiG over 14 years ago in reply to Tony Morrell

TI__Guru**** 173310 points

Tony,

I think what you are running into here is decribed in this other post: http://e2e.ti.com/support/development_tools/compiler/f/343/p/86954/300314.aspx#300314
Please take a look and see if you can adopt the solutions suggested there.

0 Tony Morrell over 14 years ago in reply to Tony Morrell

Genius 4130 points

Tony Morrell said:

My hex converter invocation is:

"C:/Program Files/Texas Instruments/TMS470 Code Generation Tools 4.7.1/bin/hex470.exe" -i -romwidth=32 -o MvMotorControlTMS570.hex MvMotorControlTMS570.elf

As far as I'm aware, I don't have a hex converter command file. Is it a TI provided file with the toolset installation that is used by default. What filename extension would it have and how is it referenced on the command line? What should it look like for a TMS570?

Hi TI guys, any thoughts on my call to hex converter? Regards, Tony.

0 AartiG over 14 years ago in reply to Tony Morrell

TI__Guru**** 173310 points

Tony,

The hex utility is expecting section sizes to be a multiple of the memory width. When you use the default memwidth of 32 for ARM, the hex utility is expecting a 4-byte alignment. Hence it is padding the .const section to satisfy the memory width requirement, which in turn is causing it to overlap with the $fill001 section.

Some suggestions to avoid the warning:
- try using the linker keyword "palign" on the .const section to place the section at an address that falls on a n-byte boundary and also pads it so that the size of section is a multiple of its placement alignment restrictions.
- change the memwidth (using -memwidth option in hex converter) such that the hex utility does not "pad" and resize the section

0 Tony Morrell over 14 years ago in reply to AartiG

Genius 4130 points

Aarti said:
Some suggestions to avoid the warning:
- try using the linker keyword "palign" on the .const section to place the section at an address that falls on a n-byte boundary and also pads it so that the size of section is a multiple of its placement alignment restrictions.
- change the memwidth (using -memwidth option in hex converter) such that the hex utility does not "pad" and resize the section

Thanks Aarti, the palign did the trick and was the best solution for me. Regards, Tony.

Code Composer Studio™︎

Code Composer Studio forum

Linker - Location of named section