What for linker read-only memory section exists?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What for linker read-only memory section exists?

I declared in linker script new memory region (ROM), defined as read only:

MEMORY
{
  text      (rx)   : ORIGIN = 0, LENGTH = 128K
  /*data      (rw!x) : ORIGIN = 0x800060, LENGTH = 0xffa0*/
  data      (rw!x) : ORIGIN = 0x800060, LENGTH = 0x7fa0
  ROM       (r)    : ORIGIN = 0x808000, LENGTH = 0x7fff
  eeprom    (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = 1K
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = 1K
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = 1K
}

Next, I put into it new section:

  .XMEM	 :
  {
	*(.XMEM*)	
  } > ROM

Everything is fine, my variables go where I wanted. I expected that read only memory section is read only, so every attempt to write something into it will result a linker error. So the test program:

#define XMEM __attribute__ ((section (".XMEM")))

XMEM int xx2;
int XMEM xx3;

int main()
{
	xx2=10;
	xx3=xx2+1;
}

Should not compile. But it compiles without any problems, warnings, errors, etc. I checked generated map file and everything is as I expected:

Name             Origin             Length             Attributes
text             0x00000000         0x00020000         xr
data             0x00800060         0x00007fa0         rw !x
ROM              0x00808000         0x00007fff         r
eeprom           0x00810000         0x00010000         rw !x
fuse             0x00820000         0x00000400         rw !x
lock             0x00830000         0x00000400         rw !x
signature        0x00840000         0x00000400         rw !x
*default*        0x00000000         0xffffffff
"¦
.XMEM           0x00808000        0x6
 *(.XMEM*)
 .XMEM          0x00808000        0x6 ksiazka.o
                0x00808002                xx2
                0x00808000                xx1
                0x00808004                xx3

So what for is read only attribute? Or how I can force gcc to generate warnings/errors when attempt to read only memory section is performed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely it's for Von Neumann architectures where some parts of the single memory map are for flash and some are RAM (and maybe some for EEPROM and SFR too). In such cases it's be normal for the linker to place anything "const" in the same non-volatile section as the code flash. Often .map files from such ARM builds have both .data and .ro.data. With .data positioned in RAM and .ro.data in code flash.

GCC on AVR is different in that we use PROGMEM for the latter to say "not part of the RAM memory space but part of the code/text memory space" because of the Harvard structure of the multiple memory spaces, each with their own location 0x0000 and addressing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, but what R attribute in memory map really do? I thought that linker will check if something tries to write to read-only region and generates an error. But it seems that linker just ignores memory region attributes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The linker does not analyse code to work out what it might do at run time - it's not THAT clever!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it does not analyze the code, so what for attributes read, write, executable are? Which tool uses it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Remember that GCC and Binutils target many architectures/platforms. It could be that it is not used at all in the avr-gcc tool chain.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about consulting the manual?
http://sourceware.org/binutils/d...

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I’ve read this documentation many times, but somehow don’t realize what for attributes exist. Thanks. So it seems that attributes are rather useless. I wonder if additional segment checking will be a nice tool, so we can catch especially on AVR platform some illegal operations, like writing to PROGMEM variables. It is common mistake, easy to catch based on segment attributes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I wonder if additional segment checking will be a nice tool, so we can catch especially on AVR platform some illegal operations

Why not just use "const" and the compiler will warn you when there's an attempted write to a const destination?