[gcc] [ld] allocation of constants problem...

[Fredczj]

Hi all,

I face a problem using gcc and ld on embedded target.
I just want to declare a constant value (designed to be located in flash memory), and I want to have it compile, linked and allocated in my output file.

For instance:

const volatile unsigned long myvar __attribute__((section(".flashdata"), used)) = 0xAAAAAAA;

using linker script with:

MEMORY
{
[...]
    flashdata_memory (wa) :         org = 0x20000000,   len = 128K
[..]
};
FORCE_COMMON_ALLOCATION

PHDRS
{
[...]
   flashdata PT_LOAD;
[...]
};

SECTIONS
{
[...]
  .flash_data   :
  {
    . = ALIGN(4);
    *(.flashdata .flashdata.*);
  }  > flashdata_memory :flashdata
[...]
}

the only way to have it allocated is to insert "a" in the section attribute as:

const volatile unsigned long myvar __attribute__((section(".flashdata, [B]\"a\"[/B]"), used)) = 0xAAAAAAA;

I find this dirty as all the variables in my section flashdata should be allocated. :yawn:
Is there a way in the linker script to force the allocation of the section?
(I hope I am not using 'allocation' word for something else..)
I thought FORCE_COMMON_ALLOCATION would help doing so, but it has no effect on my created section.

Thank you for your help,:$

Fred

[gerard4143]

Hi all,

I face a problem using gcc and ld on embedded target.
I just want to declare a constant value (designed to be located in flash memory), and I want to have it compile, linked and allocated in my output file.

For instance:

const volatile unsigned long myvar __attribute__((section(".flashdata"), used)) = 0xAAAAAAA;

using linker script with:

MEMORY
{
[...]
    flashdata_memory (wa) :         org = 0x20000000,   len = 128K
[..]
};
FORCE_COMMON_ALLOCATION

PHDRS
{
[...]
   flashdata PT_LOAD;
[...]
};

SECTIONS
{
[...]
  .flash_data   :
  {
    . = ALIGN(4);
    *(.flashdata .flashdata.*);
  }  > flashdata_memory :flashdata
[...]
}

the only way to have it allocated is to insert "a" in the section attribute as:

const volatile unsigned long myvar __attribute__((section(".flashdata, [B]\"a\"[/B]"), used)) = 0xAAAAAAA;

I find this dirty as all the variables in my section flashdata should be allocated. :yawn:
Is there a way in the linker script to force the allocation of the section?
(I hope I am not using 'allocation' word for something else..)
I thought FORCE_COMMON_ALLOCATION would help doing so, but it has no effect on my created section.

Thank you for your help,:$

Fred

First let me state that I have used linker scripts very infrequently...I'm no expert. You define .flashdata as (wa) which is Read/write and Allocatable and then you place a const volatile variable into that section, is that allowed?

[gerard4143]

First let me state that I have used linker scripts very infrequently...I'm no expert. You define .flashdata as (wa) which is Read/write and Allocatable and then you place a const volatile variable into that section, is that allowed?

Turns out it is..

[Fredczj]

Turns out it is..

thanks for your help!

i have tried to change "wa" into "ra (you are right, it is not really coherent to have read/write variable on one hand and a "const" on the other hand). But this doesn't solve the memory allocation.

I also tried to keep "wa" with non-const variable declaration, but nothing happens.

Actually, when I display the sections from my output file, I see that the only way to have a section resolved into memory image, is to have an 'ALLOC' section.
Here, with all this, when I use

objdump -h myoutput.out

I find

.flash_data   00000004  20000000  20000000  000005a8  2**2
              CONTENTS, READONLY

This (above) doesn't work.

If I use the way to work using \a\" tips I have:

.flash_data   00000004  20000000  20000000  000005a8  2**2
              CONTENTS, [B]ALLOC, [/B]LOAD, READONLY, DATA

And here, this work..

mmmm.. maybe the problem can come from 'LOAD'? do anyone know where does the 'LOAD' come from?

Your help is much appreciated!

Fred

[gerard4143]

The qualifiers const volatile require the memory section to be "aw" because you can easily step around the const volatile definition - see below

#include <stdio.h>
#include <stdlib.h>

const volatile int testint = 8;

int main(void)
{
	int *intptr = (int*)&testint;
	fprintf(stdout, "ans->%d\n", testint);
	
	*intptr = 88;

	fprintf(stdout, "ans->%d\n", testint);

	exit(EXIT_SUCCESS);
}

So the 'const volatile' is maintained by the compiler and not memory..Plus I compiled with the -S switch and it is define as .data

Why don't you just write that section in assembler like:

.section .G4143, "aw", @progbits
	.global testint
	testint: .quad 78

That way you can create your section any way you want - no second guessing

[Fredczj]

The qualifiers const volatile require the memory section to be "aw" because you can easily step around the const volatile definition - see below

#include <stdio.h>
#include <stdlib.h>

const volatile int testint = 8;

int main(void)
{
	int *intptr = (int*)&testint;
	fprintf(stdout, "ans->%d\n", testint);
	
	*intptr = 88;

	fprintf(stdout, "ans->%d\n", testint);

	exit(EXIT_SUCCESS);
}

So the 'const volatile' is maintained by the compiler and not memory..Plus I compiled with the -S switch and it is define as .data

Why don't you just write that section in assembler like:

.section .G4143, "aw", @progbits
	.global testint
	testint: .quad 78

That way you can create your section any way you want - no second guessing

Declaring assembler sections is indeed a fairly nice solution.
However, I tried to limit the number of files to maintain at maximum, and as I already make full use of linker script, I try to make it manage all the memory allocation as it should do (in good sense :-/ )

Thank you for your help. Your solution is elegant, but I keep hoping that the linker script can handle this too, don't you think?
To my mind, it is responsible to final output file creation, isn't it?

[gerard4143]

Declaring assembler sections is indeed a fairly nice solution.
However, I tried to limit the number of files to maintain at maximum, and as I already make full use of linker script, I try to make it manage all the memory allocation as it should do (in good sense :-/ )

Thank you for your help. Your solution is elegant, but I keep hoping that the linker script can handle this too, don't you think?
To my mind, it is responsible to final output file creation, isn't it?

Yes the linker ties up everything into a chosen format. Good-luck I hope everything works out..