[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] simple assembler program behaves incorrectly
From: |
Johannes Deutsch |
Subject: |
Re: [Simulavr-devel] simple assembler program behaves incorrectly |
Date: |
Thu, 28 Jul 2011 10:48:35 +0200 |
On Wed, 2011-07-27 at 19:49 +0200, Petr Hluzín wrote:
> Hello
>
> How did you build the ELF file?
avr-gcc -mmcu=attiny2313 -x assembler-with-cpp -Wa,--gstabs in.S -o
out.elf
> What are the versions of gcc, binutils and gdb? WinAR?
I use the following versions
binutils-2.2.0
avr-libc-1.70
avr-gcc-4.5.3
avr-gdb-7.2
but I don't use WinAVR. My System is Debian-Squeeze and i compiled the
avr-specific programs by hand. These programs/files are located
under /opt/avr.
> I tried this:
> avr-gcc -mmcu=atmega8 -Wa,--gdwarf2 experiment.S -o experiment.elf
> avr-objdump --all-headers --disassemble --source --debugging --syms
> experiment.elf > experiment.listing
>
> $ avr-gcc --version
> avr-gcc (WinAVR 20100110) 4.3.3
>
> The compilation produced this:
> 00000000 <__vectors>:
> 0: 12 c0 rjmp .+36 ; 0x26 <__ctors_end>
> 2: 19 c0 rjmp .+50 ; 0x36 <__bad_interrupt>
> 4: 18 c0 rjmp .+48 ; 0x36 <__bad_interrupt>
> ....
> 00000026 <__ctors_end>:
> 26: 11 24 eor r1, r1
> 28: 1f be out 0x3f, r1 ; 63 SREG
> 2a: cf e5 ldi r28, 0x5F ; 95
> 2c: d4 e0 ldi r29, 0x04 ; 4
> 2e: de bf out 0x3e, r29 ; 62 SPH
> 30: cd bf out 0x3d, r28 ; 61 SPL
> 32: 05 d0 rcall .+10 ; 0x3e <main>
> 34: 08 c0 rjmp .+16 ; 0x46 <_exit>
>
> The string `output' is compiled and stored in flash segment. If there
> are multiple initialized variables then they are grouped in a
> continuous block in flash. When the AVR is powered up, C runtime is
> expected to copy the block to RAM. The copying code should be in
> __ctors_end, but it is missing (in my attempt to reproduce your
> problem).
On my System
avr-objdump --all-headers --disassemble --source --debugging
--syms > experiment.elf
yields:
00000000 <__vectors>:
0: 12 c0 rjmp .+36 ; 0x26 <__ctors_end>
2: 17 c0 rjmp .+46 ; 0x32 <__bad_interrupt>
4: 16 c0 rjmp .+44 ; 0x32 <__bad_interrupt>
.
.
.
00000026 <__ctors_end>:
26: 11 24 eor r1, r1
28: 1f be out 0x3f, r1 ; 63
2a: cf ed ldi r28, 0xDF ; 223
2c: cd bf out 0x3d, r28 ; 61
2e: 05 d0 rcall .+10 ; 0x3a <main>
30: 08 c0 rjmp .+16 ; 0x42 <_exit>
It looks at least similar, to your output. Moreover the
'<__do_copy_data>' section is missing.
> For some reason linker is not emitting code to do the copying. This is
> not simulavr bug.
> For illustration here is the initialization part of a C program which
> is compiled with the proper code to copy .data section and zeroize
> .bss section:
> 0000008c <__ctors_end>:
> 8c: 11 24 eor r1, r1
> 8e: 1f be out 0x3f, r1 ; 63 SREG
> 90: cf ef ldi r28, 0xFF ; 255
> 92: d0 e1 ldi r29, 0x10 ; 16
> 94: de bf out 0x3e, r29 ; 62 SPH
> 96: cd bf out 0x3d, r28 ; 61 SPL
> 00000098 <__do_copy_data>:
> 98: 11 e0 ldi r17, 0x01 ; 1
> 9a: a0 e0 ldi r26, 0x00 ; 0
> 9c: b1 e0 ldi r27, 0x01 ; 1
> 9e: e8 e1 ldi r30, 0x18 ; 24
> a0: f7 e0 ldi r31, 0x07 ; 7
> a2: 00 e0 ldi r16, 0x00 ; 0
> a4: 0b bf out 0x3b, r16 ; 59
> a6: 02 c0 rjmp .+4 ; 0xac <__do_copy_data+0x14>
> a8: 07 90 elpm r0, Z+
> aa: 0d 92 st X+, r0
> ac: a0 30 cpi r26, 0x00 ; 0
> ae: b1 07 cpc r27, r17
> b0: d9 f7 brne .-10 ; 0xa8 <__do_copy_data+0x10>
> 000000b2 <__do_clear_bss>:
> b2: 11 e0 ldi r17, 0x01 ; 1
> b4: a0 e0 ldi r26, 0x00 ; 0
> b6: b1 e0 ldi r27, 0x01 ; 1
> b8: 01 c0 rjmp .+2 ; 0xbc <.do_clear_bss_start>
> 000000ba <.do_clear_bss_loop>:
> ba: 1d 92 st X+, r1
> 000000bc <.do_clear_bss_start>:
> bc: ac 3f cpi r26, 0xFC ; 252
> be: b1 07 cpc r27, r17
> c0: e1 f7 brne .-8 ; 0xba <.do_clear_bss_loop>
> c2: 0e 94 79 00 call 0xf2 ; 0xf2 <main>
> c6: 0c 94 8a 03 jmp 0x714 ; 0x714 <_exit>
So, according to you, the problem is, that the linker doesn't copy any
instructions in the binary-file, that initialize the data in the SRAM!?
Is this correct?
Maybe you have a tip, where to pose this question, to get an answer!?
Thank you very much for your quick and detailed answer, it brings at
least some light into darkness.
With best regards
Johannes D.