memory mapped using linker - gcc

Question

How can I force the linker to put some of my variables to specific place in memory. For example I want to allocate integer name in 0x8100000. If I didn't miss understand I can use:
int name __attribute__ ((section ("name_of_section")));
and then in linker scripts:
SECTIONS
{
...
. = 0x8100000;
.data : { name_of_section }
...
}
I want to use something similar for map a uC port.
But something doesn't match and I don't know where I made mistake. (I have never use linker script, so sorry if I wrote something very stupid).

Answer 1

Usually this is done without a linker script.
int volatile * const portA = 0x8100000; //portA is a constant pointer to a volatile int
...
*portA = 53; //write value 53 to output port
If you must use a linker script, it is going to be compiler and/or chip specific. Can you tell us what chip and toolchain you are using?

Answer 2

Thanks for all your advice! Now it's working.
.ld file:
SECTIONS
{
...
.data: {
...
}
...
var_name = 0x40010CA0;
}
.c file:
extern volatile int var_name;
After study docs which I linked above (Input Section Example), I tried also something like that:
.ld file:
.hrd_map 0x40010CA0 :
{
main.o(.b_section)
}
Where .b_section was a global variable with attribute:
int b __attribute__((section(".b_section")));
But it doesn't work, I got this kind of error: multiple definition of `main'.
I think that's because earlier in .ld file I have other asignment like: .data: {...} .bss .text.
Maybe someone know how to fix this, or how to get to some variables without using section attribute. I tried to look for symbols to variables in main.o file but I didn't see anything looking like symbol name for variable, except .b_section that I have created using section attribute and other (created by default? ) .data .bss .text etc.
#Dan You are right I am doing this for learning, and I agree with you. But on the other hand I think that this code will be quite portable beacuse every chip require .ld and Startup file and the definition of ports are also included in libraries.

Answer 3

I recommend NOT using the linker for access to hardware registers. Your code will be much easier to understand and maintain if you explicitly code the addresses. It is a good idea to gather all device-specific register information in an include file. For complex peripherals it is usually a good idea to typedef a structure for the register block associated with a peripheral, especially when the device supports several instances of a particular peripheral. Then use the technique from Luke's answer to get at the register or register block in your code. And the volatile keyword should always be used when accessing hardware registers.