User account creation filtered due to spam.

Bug 29141 - static constructors beyond 64k fail
Summary: static constructors beyond 64k fail
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-19 13:26 UTC by Jörg Diederich
Modified: 2010-11-29 21:39 UTC (History)
4 users (show)

See Also:
Host: Linux 2.6.16-1.2111_FC4 i686 athlon i386 GNU/Linux
Target: avr
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-10-30 16:03:06


Attachments
example source file (193 bytes, text/x-c++src)
2006-09-19 13:28 UTC, Jörg Diederich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Diederich 2006-09-19 13:26:08 UTC
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.
Comment 1 Jörg Diederich 2006-09-19 13:28:58 UTC
Created attachment 12297 [details]
example source file
Comment 2 Jörg Diederich 2006-09-19 13:36:59 UTC
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.
Comment 3 Pete Vavaroutsos 2007-02-02 22:19:42 UTC
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.
Comment 4 Eric Weddington 2008-10-30 16:03:05 UTC
See also WinAVR bug #2209796 on SourceForge:
https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2209796&group_id=68108
Comment 5 aesok 2009-01-12 20:42:15 UTC
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

Comment 6 aesok 2009-01-28 17:53:03 UTC
Fixed.
Comment 7 Michael Schulze 2010-11-26 19:21:00 UTC
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.
Comment 8 Alastair D'Silva 2010-11-29 21:39:37 UTC
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.