GNU Arm Embedded Toolchain

Variable order and location within the section - oprimization level dependent

Asked by JiriJ

Dear all,

I have been observing the difference in the variable order within the section in dependency on whether an optimization level is switched on (no O or -O1).

Code snippet:
volatile U16 try0 __attribute__ ((section (".MEM_TRY"))) __attribute__ ((aligned (2)));
volatile U16 try1[3u] __attribute__ ((section (".MEM_TRY"))) __attribute__ ((aligned (2)));
volatile U16 try2 __attribute__ ((section (".MEM_TRY"))) __attribute__ ((aligned (2)));

No optimization -- MAP FILE:

.mem_try 0x62000000 0xa
                0x62000000 . = ALIGN (0x2)
 *(.MEM_TRY)
 .MEM_TRY 0x62000000 0xa build/try.o
                0x62000000 try0
                0x62000002 try1
                0x62000008 try2

Optimization -O1 turned on -- MAP FILE:

.mem_try 0x62000000 0xa
                0x62000000 . = ALIGN (0x2)
 *(.MEM_TRY)
 .MEM_TRY 0x62000000 0xa build/try.o
                0x62000000 try2
                0x62000002 try1
                0x62000008 try0

Used GCC version: 4.7 2013q2
Target: ARM Cortex R4F big-endian

Is this behaviour expected? May you clarify this? Is there any flag by which this behaviour can be suppressed?

Many thanks in advance,
Best regards, Jiri

PS:
Yes, there are ways how to avoid this issue (direct address pointer by macro, "encapsulation"of the variables into the struct). Anyway I would like to know whether the above described approach is possible...?

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Thomas Grieger (t-grieger) said : 		#1

Hi Jiri,

can you provide a sample of the source code and/or assembler in which the variables are accessed? Maybe the compiler rearranges the variables to align them to the access order.

Best regards,
Thomas

Revision history for this message
JiriJ (jirij-0) said : 		#2

Hello Thomas,
currently the variables are not accessed anywhere - there is just the definition in this example (so the compiler should not be inspired for any rearranging, should not ;-)).

Similar variables in a real application will play a role of external registers. In most cases they will be accessed seperately - no sequence of incrementing pointer etc.
If I tried to locate another sets of variables (a few structs and arrays) and always got "the same" results - the order of the variables within any section is opposite...
Fo an instance:
                no optimization
                0x64008000 aaa
                0x64008034 bbb
                0x64008050 ccc
                0x640080a0 ddd
                0x640080b0 eee

                -O1 level
                0x64008000 eee
                0x6400800e ddd
                0x6400801e ccc
                0x6400806e bbb
                0x6400808a aaa

Thanks for any hint,
Best regards, JiriJ

Revision history for this message
Thomas Grieger (t-grieger) said : 		#3

Hi Jiri,

according to the manual of the gcc the option '-fno-toplevel-reorder' may be the one you are looking for.

As there is at least one disadvantage you should still watch out for other options. Especially if the problem is locating variables to special addresses to use them for register access. Maybe your processor vendor already offers some header files to solve this problem. Freescale (I'm using a Kinetis K70) for example provides a large header file with struct and maro definitions for nearly all registers.

Best regards,
Thomas

Revision history for this message
Joey Ye (jinyun-ye) said : 		#4

Echo Thomas that -fno-toplevel-reorder maybe the right answer. Furthermore this option is enabled by default only in -O0, which explains why -O0 and -O1 are different.

Thanks,
Joey

Revision history for this message
JiriJ (jirij-0) said : 		#5

Hello Thomas,

thanks for your advice a lot (yes, you could just tell me - RTFM ;-)) - yes, it works properly!

One drawback of this flag is that is applied at the global scope. In the GCC manual there is stated: "For new code, it is better to use attributes." Well, I am trying to search a right variable attribute/pragma which can be used just in the local scope (within one module) but still not revealed :-/

Best regards, JiriJ

Revision history for this message
Joey Ye (jinyun-ye) said : 		#6

No idea either. This is the perfect question to be asked in gcc-help mail list.

Joey

Can you help with this problem?

Provide an answer of your own, or ask JiriJ for more information if necessary.

To post a message you must log in.