ARMCLANG: The order of sections/symbols in output image file

Information in this knowledgebase article applies to:

• MDK v5.x
• ARMCC compiler toolchain v5.x
• ARMCLANG compiler toolchain v6.x

QUESTION

If a few const arrays are defined in a module called langpack as follows:

const int g_LangInfo1[] ={
…
};

const char g_FontExt1_1[] = {
…
};

const int g_FontExt1_2[] = {
…
};

const char g_FontExt0_1[] = {
…
};

when it is compiled and linked by ARMCC compiler toolchain v5.x, the order of symbols/sections in the object module langpack.o shown in the map file is as follows:

    g_LangInfo1                              0x0800994c   Data          20  langpack.o(.constdata)
    g_FontExt1_1                             0x08009960   Data           3  langpack.o(.constdata)
    g_FontExt1_2                             0x08009964   Data          16  langpack.o(.constdata)
    g_FontExt0_1                             0x08009974   Data           2  langpack.o(.constdata)

which follows the same order as written in the source code.

But when it is compiled and linked by ARMCLANG compiler toolchain v6.x, the order of sections in the object module langpack.o shown in the map file is alphabetic as follows:

    g_FontExt0_1                             0x0800fa28   Data           2  langpack.o(.rodata.g_FontExt0_1)
    g_FontExt1_1                             0x0800fa2a   Data           3  langpack.o(.rodata.g_FontExt1_1)
    g_FontExt1_2                             0x0800fa30   Data          16  langpack.o(.rodata.g_FontExt1_2)
    g_LangInfo1                              0x0800fa40   Data          20  langpack.o(.rodata.g_LangInfo1)

Why is there such a difference in ARMCC and ARMCLANG compiler toolchain?

ANSWER

Generally speaking, there is no guarantee that the order of objects in an output image is relative to their order in the source file. A program should not rely on any specific order that can change between different compilers, or from one toolchain version to another, using different compiler options, using different order of object files given to the linker, etc.

If a specific order is required for some reason, a struct type can be used, for example:

struct LangInfo {
  int LangInfo1[A];
  char FontExt1_1[B];
  int FontExt1_2[C];
  char FontExt0_1[D];
/* etc */

} g = {
{ /* initialiser for LangInfo1 */ },
{ /* initialiser for FontExt1_1 */ },
{ /* initialiser for FontExt1_2 */ },
{ /* initialiser for FontExt0_1 */ },
/* etc */
};

ARMCLANG compiler by default puts each variable in a separate section, whereas with ARMCLANG these sections have different section names, which include the variable names, for example, '.rodata.a', '.rodata.b', etc for variables 'a', 'b', etc.

In ARMCC they are placed by default into the same section, which has the same name, for example '.constdata'.

The order of sections in the output image is then controlled by the --sort option to armlink. The default sort algorithm is 'Lexical'. That's why in the ARMCLANG case above, the variables are laid out alphabetically in the output file.

To prevent the linker from reordering the variables, they can be put in the same section. With ARMCLANG this can be achieved in a couple of ways:

• use the -fno-data-sections option
• use __attribute__((section(NAME))) with all variables, giving the same section name. Note that while current behaviour of the compiler is to emit the variables in the same section in the declaration order, this can change at any time and any future compatibility cannot be guaranteed in that respect.
• A third alternative is to use the __attribute__((section(NAME))) separately for each variable, using different section names. The armlink will arrange the sections lexicographically, hence the order can be controlled by choosing section names.

MORE INFORMATION

• Refer to Arm compiler Migration and Compatibility Guide

Last Reviewed: Wednesday, December 2, 2020