×

Discussion Board

Results 1 to 6 of 6
  1. #1
    Registered User
    Join Date
    Oct 2008
    Posts
    3

    Works fine in Debug mode, not in Release mode. Why?

    Dear all. I'm currently developing an application for smartphone using Carbide 1.3 with S60 3rd fp2.
    Recently found out that my application crashes when compiled with GCCE release mode(UREL), while it works perfectly when compiled with GCCE debug mode(UDEB), or when running by emulator(WINSCW).

    The problem lied in that some of the variables were not properly assigned of correct values.

    It seems to be caused by the bug in the GCCE compiler, to see the following C code and assembly.

    unsigned int aa,bb;
    aa=1;
    unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;
    pbb=(unsigned short*)&bb;

    *pbb++=*paa++;
    *pbb=*paa;
    fprintf(fp,"%d",bb);
    Of course, the result should be that '1' is copied from aa to bb.
    However, when compiled with GCCE release mode, some odd value was assigned to bb, instead of 1.

    Following is the disassembly for the C code above.
    0x78744620 mov r3,#0x1
    0x78744624 str r3,[r11,#-72]
    0x78744628 ldrh r3,[r11,#-72]
    0x7874462c cpy r5,r0
    0x78744630 ldr r1,[pc,#48]
    0x78744634 strh r3,[r11,#-76]
    0x78744638 ldrh r3,[r11,#-70]
    0x7874463c ldr r2,[r11,#-76]
    0x78744640 strh r3,[r11,#-74]

    The problem is that, just before the last instruction, in 0x7874463c(red colored), the value of bb is already loaded into R2, even before the final process of copying upper two bytes of aa into bb takes place in the last instruction, 0x78744640(blue colored)

    This results in wrong value of bb is passed to fprintf.(Strictly speaking, uppers two bytes of 4byte-bb is uninitialized)


    What is more weird, if you add some seemingly irrelevant code above, it begins to work fine. For example,

    volatile unsigned int aa,bb;
    aa=1;
    volatile unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;

    or

    unsigned int aa,bb;
    aa=1;
    fprintf(fp,"%d",bb);
    unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;


    Here are my questions;
    Is this a known issue? What can I do then? Upgrade GCCE? How?(I'm not quite sure about the version of my GCCE, since it was automatically installed along with carbide, but I guess it's GCC 3.4.3)

    Thanks

  2. #2
    Registered User
    Join Date
    Oct 2008
    Posts
    3

    Works fine in Debug mode, not in Release mode. Why?

    Dear all. I'm currently developing an application for smartphone using Carbide 1.3 with S60 3rd fp2.
    Recently found out that my application crashes when compiled with GCCE release mode(UREL), while it works perfectly when compiled with GCCE debug mode(UDEB), or when running by emulator(WINSCW).

    The problem lied in that some of the variables were not properly assigned of correct values.

    It seems to be caused by the bug in the GCCE compiler, to see the following C code and assembly.

    unsigned int aa,bb;
    aa=1;
    unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;
    pbb=(unsigned short*)&bb;

    *pbb++=*paa++;
    *pbb=*paa;
    fprintf(fp,"%d",bb);
    Of course, the result should be that '1' is copied from aa to bb.
    However, when compiled with GCCE release mode, some odd value was assigned to bb, instead of 1.

    Following is the disassembly for the C code above.
    0x78744620 mov r3,#0x1
    0x78744624 str r3,[r11,#-72]
    0x78744628 ldrh r3,[r11,#-72]
    0x7874462c cpy r5,r0
    0x78744630 ldr r1,[pc,#48]
    0x78744634 strh r3,[r11,#-76]
    0x78744638 ldrh r3,[r11,#-70]
    0x7874463c ldr r2,[r11,#-76]
    0x78744640 strh r3,[r11,#-74]

    The problem is that, just before the last instruction, in 0x7874463c(red colored), the value of bb is already loaded into R2, even before the final process of copying upper two bytes of aa into bb takes place in the last instruction, 0x78744640(blue colored)

    This results in wrong value of bb is passed to fprintf.(Strictly speaking, uppers two bytes of 4byte-bb is uninitialized)


    What is more weird, if you add some seemingly irrelevant code above, it begins to work fine. For example,

    volatile unsigned int aa,bb;
    aa=1;
    volatile unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;

    or

    unsigned int aa,bb;
    aa=1;
    fprintf(fp,"%d",bb);
    unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;


    Here are my questions;
    Is this a known issue? What can I do then? Upgrade GCCE? How?(I'm not quite sure about the version of my GCCE, since it was automatically installed along with carbide, but I guess it's GCC 3.4.3)

    Thanks

  3. #3
    Registered User
    Join Date
    Oct 2008
    Posts
    3

    GCCE compiler bug?

    Dear all. I'm currently developing an application for smartphone using Carbide 1.3 with S60 3rd fp2.
    Recently found out that my application crashes when compiled with GCCE release mode(UREL), while it works perfectly when compiled with GCCE debug mode(UDEB), or when running by emulator(WINSCW).

    The problem lied in that some of the variables were not properly assigned of correct values.

    It seems to be caused by the bug in the GCCE compiler, to see the following C code and assembly.

    unsigned int aa,bb;
    aa=1;
    unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;
    pbb=(unsigned short*)&bb;

    *pbb++=*paa++;
    *pbb=*paa;
    fprintf(fp,"%d",bb);
    Of course, the result should be that '1' is copied from aa to bb.
    However, when compiled with GCCE release mode, some odd value was assigned to bb, instead of 1.

    Following is the disassembly for the C code above.
    0x78744620 mov r3,#0x1
    0x78744624 str r3,[r11,#-72]
    0x78744628 ldrh r3,[r11,#-72]
    0x7874462c cpy r5,r0
    0x78744630 ldr r1,[pc,#48]
    0x78744634 strh r3,[r11,#-76]
    0x78744638 ldrh r3,[r11,#-70]
    0x7874463c ldr r2,[r11,#-76]
    0x78744640 strh r3,[r11,#-74]

    The problem is that, just before the last instruction, in 0x7874463c(red colored), the value of bb is already loaded into R2, even before the final process of copying upper two bytes of aa into bb takes place in the last instruction, 0x78744640(blue colored)

    This results in wrong value of bb is passed to fprintf.(Strictly speaking, uppers two bytes of 4byte-bb is uninitialized)


    What is more weird, if you add some seemingly irrelevant code above, it begins to work fine. For example,

    volatile unsigned int aa,bb;
    aa=1;
    volatile unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;

    or

    unsigned int aa,bb;
    aa=1;
    fprintf(fp,"%d",bb);
    unsigned short* paa,*pbb;
    paa=(unsigned short*)&aa;


    Here are my questions;
    Is this a known issue? What can I do then? Upgrade GCCE? How?(I'm not quite sure about the version of my GCCE, since it was automatically installed along with carbide, but I guess it's GCC 3.4.3)

    Thanks

  4. #4
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,697

    Re: Works fine in Debug mode, not in Release mode. Why?

    You already have this post in http://discussion.forum.nokia.com/fo...d.php?t=147848
    Yes, I also see that there are no replies, however you have to accept it:
    - for coding in Symbian C++ it is not necessary to know ARM assembly
    - for coding in Symbian C++ it is not necessary to participate in development of GCC
    - the construct you are experimenting with is at least a rare one.
    Are you using any optimization switches?

  5. #5
    Nokia Developer Moderator
    Join Date
    Sep 2004
    Location
    Tampere, Finland
    Posts
    11,359

    Re: Works fine in Debug mode, not in Release mode. Why?

    The GNU compiler is provided by CodeSourcery, LLC and its release notes state:

    ...
    ==========
    4. Support
    ==========

    CodeSourcery does not provide free support for these packages.

    CodeSourcery does provide paid support (including installation
    assistance, defect correction, etc.) for these packages and for the
    GNU Toolchain in general. Please send mail to info@codesourcery.com
    if you are interested in purchasing support for the GNU Toolchain.

    ...
    -- Lucian

    If you are not yet a DVLUP member it is time to correct that mistake :) Click here to join: http://www.dvlup.com/lucian/Invite

  6. #6
    Registered User
    Join Date
    May 2009
    Posts
    11

    Re: Works fine in Debug mode, not in Release mode. Why?

    I too have been experiencing "release build only" problems, and in my efforts came across an answer to your problem:
    See "Casting does not work as expected when optimization is turned on." in
    A list of common GCCE NON BUGS.

    Release mode turns on optimization, which relies on the types of aliased objects to be correct; if they're not correct, you get undefined behavior like you're experiencing. In your case the problem is using an 'unsigned short *' containing the address of an 'unsigned int'.

    Try:
    Code:
    ...
    unsigned int *paa = &aa, *pbb = &bb; 
    ...
    That should allow the compiler to optimize while keeping everything correct. Hope this helps

Similar Threads

  1. Replies: 3
    Last Post: 2004-04-16, 10:19
  2. IMP: Running Push Midlet works fine with OTA!
    By mfhorizon in forum Mobile Java General
    Replies: 1
    Last Post: 2003-12-06, 15:22
  3. mildet works fine in emulator when running from JBuilder...
    By Psychocrackpot in forum Mobile Java General
    Replies: 1
    Last Post: 2003-08-01, 07:32
  4. Replies: 5
    Last Post: 2003-05-02, 03:04

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×