Sixteen or more bytes of uninitialized global variables in a program will
cause gcc to generate an incorrect opcode in __do_clear_bss in the startup
for the avr target as shown in this example.
Source file, t.c:
char x[16];
int main(void) { }
Compile script:
avr-gcc -c -mmcu=atmega88 -o t.o t.c
avr-gcc -mmcu=atmega88 -Wl,-mavr4 -Wl,--oformat=ihex,-s t.o -o t.hex
avr-gcc -g -mmcu=atmega88 -Wl,-mavr4 t.o -o t.elf
avr-objdump -dSCg t.elf > t.lst
Output t.lst, lines 68,69:
00000060 <.do_clear_bss_start>:
60: a0 31 cpi r26, 0x10 ; 16
Output t.hex, line 8:
:100056001160A0E1B16001C01D92B031B107E1F7B6
The listing is correct, "a0 31", but the hex file is wrong, "B031".
And, indeed, test programs fail to execute on real hardware with 16
or more bytes of BSS, but _do_ execute with less.
The relevant source file is gcc-4.0.2/gcc/config/avr/libgcc.S, line 727.
But I'm having difficulty finding the actual bug.
I'm using Mandriva Linux 2006 (2.6.12-12mdk) and compiled from source
binutils-2.16.1, gcc-4.0.2, and avr-libc-1.4.3.
$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../configure --target=avr --host=i686-pc-linux-gnu
--disable-shared --disable-nls --enable-languages=c,c++
Thread model: single
gcc version 4.0.2
Note: This is a tiny wrinkle in an excellent piece of software.
I thank everyone that works on gcc and related projects.
--
Summary: Incorrect opcode in __do_clear_bss if bss has more than
15 bytes
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: KenJackson at ieee dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26396
