How to set a variable in SRAM in its ad?

Just recently started to learn assembler AVR, the Atmega8 controller using the compiler AVR-GCC. And the question arose - how can I set a variable in SRAM when you declare the section .data? Under the AVRASM2 compiler this is done, as I understand it, something like this:
.DSEG
variable: .byte 0xff

However, similar code for AVR-GCC does not lead to a similar result:
.data
variable: .byte 0xff

Actually, at the address 0x0060 is some sort of garbage which has nothing to do with the fact that I wanted to put. However, if we look at the size of the program using avr-size, we'll see what we have in the section .data occupied 2 bytes:
AVR Memory Usage
----------------
Device: atmega8

Program: 64 bytes (0.8% Full)
(.text + .data + .bootloader)

Data: 2 bytes (0.2% Full)
(.data + .bss + .noinit)

If of ad to remove the variable value (0xff) in the section date will be 0 bytes. In the file .lst we see this happening in the section .data:
Disassembly of section .data:

00800060 <_edata-0x2>:
 800060: ff 00 .word 0x00ff ; ????


Why the compiler is trying to stick in the memory word, and why these data (word or byte) in the end do not fall in memory? And whether it is necessary to declare the data might be better when you initialize completely clear the SRAM at the start of the controller?
March 20th 20 at 12:36
1 answer
March 20th 20 at 12:38
Solution
Actually, at the address 0x0060 is some sort of garbage which has nothing to do with the fact that I wanted to put.

Where did the address 0x0060, and you see what is there?

TL;DR: the code copies data from FLASH to SRAM and Abdoulaye .bss does not link by default. gcc inserts a reference to an undefined symbols __do_copy_data and __do_clear_bss within each translation unit that defines the objects in the partition .data and .bss, respectively. Written by hand in assembler files, they may be mentioned explicitly.
Address 0x0060 is the address of variable in SRAM. From the Atmega8 SRAM starts from the address (page 18 dataset), respectively, the first variable will be written there. File .this confirms the lst is a variable of variables is replaced by the compiler at the address 0x0060.

What there is, I understand in the following code:
#include <avr/io.h>

// ================= Section SRAM =================
 .section .data
variable: .byte 0xff

// ================= Section FLASH ================
 .section .text
 .global main

main: // Set PORTD for output.
 ldi r16, 0xff 
 out _SFR_IO_ADDR(DDRD), r16
 // PORTD all pins set to zero.
 clr r16
 out _SFR_IO_ADDR(PORTD), r16

 // Loaded from SRAM a value that lies at variable.
 // Expect all the port D pins will accept value 1...
 lds r16, variable
 out _SFR_IO_ADDR(PORTD), r16

 // ... but this is not happening.
 rjmp while

// An infinite loop.
while loop: rjmp while


Therefore, if we have in memory at the address pointed to by the variable was the value 0xff, then all the conclusions of PORTD would stand up to one. However, this is not happening.

Here is the main procedure in the lst file:
38: 0f ef ldi r16, 0xFF ; 255
 3a: 01 bb out 0x11, r16 ; 17
 3c: 00 27 eor r16, r16
 3e: 02 bb out 0x12, r16 ; 18
 40: 00 91 60 00 lds r16, 0x0060 ; 0x800060 <__EEPROM_REGION_LENGTH__+0x7f0060>
 44: 02 bb out 0x12, r16 ; 18
 46: 00 c0 rjmp .+0 ; 0x48 <while>


It's definitely not a problem of the port itself - I tested this by setting back the value 0xff, pre-loaded with the command ldi in RON. Correctly behaving code, if before the download RON of SRAM the value of the variable pre-load it into SRAM using the command sts. Ie, the value is not set only at initialization section .data - rowan commented on March 20th 20 at 12:41
Ie, the value is not set only during initialization in sigchi .data

OK. As you stitch the resulting software and how it is run? it's -- I mean, in SRAM, data must be copied from flash at start of the program-where is it happening?

Here I look in AVR ELF one of their projects and see the following:

Sections:
Idx Name Size VMA LMA File off Algn
 0 .data 00800100 00001db0 00001e44 00000124 2**0
 CONTENTS, ALLOC, LOAD, DATA
...

00000000 <__vectors>:
 0: 19 c0 rjmp .+50 ; 0x34 <__ctors_end>

...

00000034 <__ctors_end>:
 34: 11 24 eor r1, r1
 36: 1f be out 0x3f, r1 ; 63
 38: cf ef ldi r28, 0xFF ; 255
 3a: d4 e0 ldi r29, 0x04 ; 4
 3c: de bf out 0x3e, r29 ; 62
 3e: cd bf out 0x3d, r28 ; 61

00000040 <__do_copy_data>:
 40: 12 e0 ldi r17, 0x02 ; 2
 42: a0 e0 ldi r26, 0x00 ; 0
 44: b1 e0 ldi r27, 0x01 ; 1
 46: e0 eb ldi r30, 0xB0 ; 176
 48: fd e1 ldi r31, 0x1D ; 29
 4a: 02 c0 rjmp .+4 ; 0x50 <__do_copy_data+0x10>
 4c: 05 90 lpm r0, Z+
 4e: 0d 92 st X+, r0
 50: a4 32 cpi r26, 0x24 ; 36
 52: b1 07 cpc r27, r17
 54: d9 f7 brne .-10 ; 0x4c <__do_copy_data+0xc>


-- this code koprowski data .data from flash to SRAM directly from the vector, we reset it come.
The dump clearly seen LMA data is loaded into the register pair Z (at the addresses 46-48), VMA is loaded into the register pair X (addresses 42 to 44) and an end address of data (check on address 50-52). - Mikayla32 commented on March 20th 20 at 12:44
Start simply by applying power to the microcontroller) To every output port D connected to LEDs on them I determine what is the status of each output.

Assemble using tools from avr-toolchain:
avr-gcc-mmcu=atmega8 -Xassembler -ggdb -o bin\Test.o test.S
avr-gcc -g-mmcu=avr4 -o bin\Test.elf bin\Test.o
avr-objcopy -j .text-j .data-O ihex bin\Test.elf bin\Test.hex


Received hex is loaded into the controller using usbasp programmer:
avrdude -p atmega8 -c usbasp -U flash:w:bin\Test.hex
- rowan commented on March 20th 20 at 12:47
Start simply by applying power to the microcontroller)

I'm not talking about that. What exactly is run from the reset vector? I have in previous comments and added that happens to me in the working draft for comparison. - Mikayla32 commented on March 20th 20 at 12:50
Indeed, code like <__do_copy_data> I have - after initializing the stack, it goes directly in main:
Disassembly of section .text:

00000000 <__ctors_end>:
 0: 12 c0 rjmp .+36 ; 0x26 <__init>
 // Here is the interrupt table...

00000026 <__init>:
 26: 11 24 eor r1, r1
 28: 1f be out 0x3f, r1 ; 63
 2a: cf e5 ldi r28, 0x5F ; 95
 2c: d4 e0 ldi r29, 0x04 ; 4
 2e: de bf out 0x3e, r29 ; 62
 30: cd bf out 0x3d, r28 ; 61
 32: 02 d0 rcall .+4 ; 0x38 <main>


It's weird - never seen information about what to load in SRAM need to separately register in the compiler. - rowan commented on March 20th 20 at 12:53
never seen information about what to load in SRAM need to separately register in the compiler.

I do not specifically prescribed by this code came from the library. That's my Makefile: https://github.com/Mikayla32/stove/blob/master/sw/s...

avr-gcc -g-mmcu=avr4

avr4 slightly confused here. From this also depends on the script of the linker and all that. - Mikayla32 commented on March 20th 20 at 12:56
I do not specifically prescribed by this code came from the library.

Maybe so gcc compiles C code.

avr4 slightly confused here.

This all right is the processor architecture. I replaced the atmega8 and added -c to create the file .o - the result has not changed. In the map file it can be clearly seen - all the libraries are loaded from /lib/gcc/avr/5.4.0/../../../../avr/lib/avr4/. Including the library libgcc.a, which, if you believe the documentation, and should section .init4 to load the data into SRAM.

Thank you for Your answers, thanks to them was able to get to the truth. In order for the compiler added procedure __do_copy_data, it must explicitly declare:
.global __do_copy_data

Then the compiler adds code to fill the data in SRAM from Flash, which You wrote earlier. - rowan commented on March 20th 20 at 12:59
In order for the compiler added procedure __do_copy_data, it must explicitly declare:
.global __do_copy_data
Then the compiler adds code to fill the data in SRAM from Flash, which You wrote earlier.

@rowan, Yes .global __do_copy_data creates a link to the symbol and the linker his pelinkovec to the program.

Maybe so gcc compiles C code

Yes, really. Interesting method of optimization. - Mikayla32 commented on March 20th 20 at 13:02

Find more questions by tags AssemblerGCCAtmel AVR