[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] strange c++ obiect initialization problems (full code

From: Marcin S
Subject: Re: [avr-gcc-list] strange c++ obiect initialization problems (full code included)
Date: Mon, 13 Jun 2011 07:15:23 +0000

2011/6/12 Georg-Johann Lay <address@hidden>:
> Marcin S schrieb:
>> 2011/6/11 Georg-Johann Lay <address@hidden>:
>>> Marcin S schrieb:
>>>> 2011/6/9 Georg-Johann Lay <address@hidden>:
>>>>> Marcin S schrieb:
>>>>>> Hello there,
>>>>>> from time to time i have a strange problems when initializing
>>>>>>  class objects in file range by their respective
>>>>>> constructors, i noted that problem occurs only when that
>>>>>> constructors takes pointers to other global objects, tables
>>>>>> or something else.
>>>>>> Whats the problem? in best scenario object pointer are
>>>>>> wrongly set and pointing to some random locations, at worst
>>>>>> my program does not start at all (event with my main() func
>>>>>> empty) it just hangs
>>>>>> here is link to my code
>>>>>> http://dl.dropbox.com/u/6883398/Lays.tar.bz2 its and eclipse project,
>>>>>> simple "make" in project directory should work too.
>>>>>> Note that archive contains already compiled program in
>>>>>> "Release" directory, this compilation does not work at all!
>>>>>> (worst case scenario described above).
>>>>>> As I wrote this program incrementaly it stopped working after
>>>>>> i added 2 objects inits in layouts.cpp
>>>>>> CLayPGMString minTag(minTagData,strMin,true,CLayPGMString::XSMALL);
>>>>>> CLayPGMString maxTag(maxTagData,strMax,true,CLayPGMString::XSMALL);
>>>>>> strMin and strMax params are pointers to strings in PROGMEM,
>>>>>> if i replace it with zeros like
>>>>>> CLayPGMString
>>>>>> minTag(minTagData,0,true,CLayPGMString::XSMALL); CLayPGMString
>>>>>> maxTag(maxTagData,0,true,CLayPGMString::XSMALL);
>>>>>> program starts again.
>>>>>> Other important thing noted is, when I initialise those
>>>>>> objects in file range with their default, empty constructors
>>>>>> and then set needed pointers at run time (for example right
>>>>>> after main() function) everything works too. I ran out of
>>>>>> ideas what could be wrong, maybe wrong code, I'm open to any
>>>>>> suggestions.
>>>>>> I'm using avr-gcc-4.5.2 on gentoo linux, also checked on
>>>>>> stable 4.4 and it behaves exactly the same way.
>>>>>> Marcin
>>>>> Do you see r20 used in one of the functions? Reminds me of
>>>>> http://gcc.gnu.org/PR45263 which is not yet backported to
>>>>> avr-gcc < 4.6
>>>>> Johann
>>>> Hej Johann,
>>>> I'm not sure if i checked it correctly, I've opened .lss file
>>>> corresponding to my program and yes, there are some r20
>>>> operations in this function.
>>>> Excuse me my lack of knowledge of low lvl stuff, but You think
>>>> this might cause the problem?
>>> That depends on the hardware you use. The problem will not occur on
>>> devices <= 64 kib flash. Look at the code again. In the startup
>>> code that runs before main you might see use of r20 around calls to
>>> you function. Note that these calls will be indirect, so searching
>>> for symbol will not help. Using r20 that way in startup can cause
>>> problems because is is callee-used register and the callee can
>>> clobber it, leaving its content in a mess in startup code.
>>>> Marcin
>>> Johann
>> Hi, It's atmega128, so r20 still is a main suspect.
>>> Note that these calls will be indirect, so searching for symbol
>>> will not help.
>> Umm, then I'm afraid I dont know how to check it.
>> Btw. I tried to confirm this thinking by building 4.6.1 avr-gcc but i
>> think its buggy atm (dwarf2 bug) and i am unable to build any
> Yes, that's PR48459: DWARF is unusable in current 4.6 and 4.7, so using
> DWARF or configuring with --with-dwarf2 will abort.
> If you build the compiler on your own, you can simply copy
> ./gcc/config/avr/libgcc.S
> from 4.6 or 4.7 into your 4.5 sources. Or you can build 4.6 without dwarf
> and copy the generated libgcc.a's in respective places in your installed
> compiler (no matter if win32 or linux).
>> project with it. I'll wait till it will be usable and let You know.
>> Marcin.

I've picked this way
> Or you can build 4.6 without dwarf
> and copy the generated libgcc.a's in respective places in your installed
> compiler

did that with my current 4.4 ... and its working! :-D at least on
early testing (but couldnt hold myself with sharing it now :P)
I also checked another project, bigger, with simmilar issues in wchich
i had to reinitialize almost all pointers at run-time to get it
working - now its okay witout it.

Thanks You very much for assistance.


reply via email to

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