simulavr-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]