Contruction of global static objects fails while using flash adresses over 0xFFFF, e.g. for bootloader purposes. avr mcu hangs completly before main or even the called constructor itself. minimal gcc call: avr-c++ -c -mmcu=at90can128 -I. -I. -g -O0 -Wall -Wextra -Wshadow -Wpointer-arith -Wcast-align -Wsign-compare -Waggregate-return -Wunused -fno-exceptions a_test.cpp -o a_test.o linked with the following options -Wl,-Map=a_test.map,--cref,--section-start=.text=0x1F000 short example code in attachment.
Created attachment 12297 [details] example source file
thanks to joerg wunsch, additional information is already available. #ifdef L_ctors .section .init6,"ax",@progbits .global __do_global_ctors __do_global_ctors: ldi r17, hi8(__ctors_start) ldi r28, lo8(__ctors_end) ldi r29, hi8(__ctors_end) rjmp .do_global_ctors_start .do_global_ctors_loop: sbiw r28, 2 mov_h r31, r29 mov_l r30, r28 XCALL __tablejump__ .do_global_ctors_start: cpi r28, lo8(__ctors_start) cpc r29, r17 brne .do_global_ctors_loop #endif /* L_ctors */ using r28/r29 only works for data <64k. r30/r31 are filled with wrong data in return, in detail 64k less than intended.
I too have ran into this problem. The code in __tablejump__ that calls the constructors is using LPM instructions instead of ELPM, so the value in the RAMPZ register is being ignored. Thus a bad pointer to the constructor is fetched.
See also WinAVR bug #2209796 on SourceForge: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2209796&group_id=68108
Subject: Bug 29141 Author: aesok Date: Mon Jan 12 20:41:57 2009 New Revision: 143306 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143306 Log: PR target/29141 * config/avr/t-avr (LIB1ASMFUNCS): Add _tablejump_elpm. * config/avr/libgcc.S (__do_global_ctors, __do_global_dtors): Add variant for devices with 3-byte PC. (__tablejump_elpm__) : New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/libgcc.S trunk/gcc/config/avr/t-avr
Fixed.
In my opinion this bug is still pending and not fixed. The proposed fix uses register r20 but this could be clobbered by constructor that are called, leading to destructing the exit condition of the __do_global_ctors loop. In new version of gcc (see bug 45263 but still not confirmed) this is weakly fixed by pushing and poping r20 around the constructor call. I would suggest using a register between r2-r17 instead of r20. According to the compiler abi this should be a register that the called routine has to save if it needs to use it.
Michael, I agree. I authored the other patch, but did not have enough knowledge of GCC for a proper solution. The patch offered in bug 45263 was a workaround based on what I could observe. Could you please offer a patch? I can test it and add it to MHV AVR Tools.