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
short example code in attachment.
Created attachment 12297 [details]
example source file
thanks to joerg wunsch, additional information is already available.
ldi r17, hi8(__ctors_start)
ldi r28, lo8(__ctors_end)
ldi r29, hi8(__ctors_end)
sbiw r28, 2
mov_h r31, r29
mov_l r30, r28
cpi r28, lo8(__ctors_start)
cpc r29, r17
#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:
Subject: Bug 29141
Date: Mon Jan 12 20:41:57 2009
New Revision: 143306
* 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.
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.
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.