GCCE ‘support’ in the 3rd edition SDK

(update at 19:15, ho-hum, after the griping I found the Maintenance Release notes on Forum Nokia, which do recommend setting the optimization options in gcce.mk.)

It has been ‘generally known’ that binaries produced by GCCE (the CSL ARM gcc toolchain) for 9.1 are larger than what we’ve been used to. The Jaiku SIS file clocks in at about 700k on 2nd edition, but around 1400k on 3rd. The suggested solution is to purchase RVCT from ARM (for several thousand USD per seat).

I was digging into the compiler flags used because I was getting corrupt binaries (as in not being able to start on the device, giving error -20 (KErrCorrupt) instead) when building in the CodeWarrior IDE (another few thousand, but the only way to do on-device debugging).

Turns out that the Symbian/Nokia build tools enable no optimization whatsoever on GCCE. There’s just a comment in the ide_cw.pl:

#       gcc version 3.4.3 (release) (CodeSourcery ARM Q3cvs 2004) 
#       -- currently link fails when building with -O4
#       $compilerargs .= " -O4 "

I guess it goes without saying that the SDK is not using the Q3 2004 version, but a Q1 2005 one.

The SDK also states that ‘The Symbian OS builds tools apply the following policy when building projects: kernel-side code is built for ARM, while other code (user-side) is built for THUMB’. So does that mean your code is built with the THUMB instruction set? Of course not. It’s just in the SDK to confuse you.

So changing gcce.mk and ide_cw.pl to use -Os -mthumb drops the SIS file size down to 880k, which although not very nice compared to 670, is a whole lot better than 1400.

I’m now postponing purchasing RVCT and checking whether the compiler options break anything.

Maybe Nokia and Symbian could document if there are any known issues with optimization and the version of GCCE actually shipped. Even better, it would be nice to know whether we could upgrade to the 2005 Q3 version from CodeSourcery.

Ah, and the KErrCorrupt was caused by command-line tools thinking the link name of dlls to be something like jaikusettings{000a0000}[20006e42].exe and the IDE saying that it was ngs{000a0000}[0x20006e42].exe. Note the crucial 0x. Just another thing to modify in our version of the build scripts, together with specifying no optimization for the GCCE UDEB build when SRCDBG is given, just like with RVCT.

This entry was posted in Symbian. Bookmark the permalink.

4 Responses to GCCE ‘support’ in the 3rd edition SDK

  1. XYZ says:

    Looks like you have RVCT for testing. How is the difference in case of performance to gcce ?
    Do you really want to build with thumb code ? The performance to size relationship isn’t good for that in the current phones. Maybe I’m wrong ?

  2. Mika says:

    No, I don’t have RVCT yet, sorry.

    I’m not sure about thumb, I’m still testing. It does produce smaller code, and our bottlenecks are generally not in pure code, rather in drawing and disk access.

  3. Mika, very good catch… It seems S60 3rd FP1 is getting better. I found this line in the gcce.mk file:

    REL_OPTIMISATION=-O2 -fno-unit-at-a-time

    Note: Your captcha setting may be too “strong” Even human being (like me) has to tried it several times before your server accept it.