Hack Bada IDE: collect as we want

Hello!
This short article is addressed to the developers of applications for the Samsung Bada mobile platform, who don’t want to put up with the idea that Samsung “knows better what is needed”, as well as people involved in building ARM code using the GNU Compiler Collection.

I think many people noticed that when building a project in Target-Release or Target-Debug, a log is written like

arm-samsung-nucleuseabi-g++ -DSHP -I"D:/Work/Bada/1.2.1/include" -I"???/inc" -Os -Wall -E -fpic -fshort-wchar -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mlittle-endian -mthumb-interwork -o"???/Target-Release/dirent.i" "../src/bada/dirent.cpp"
'Finished building: ../src/bada/dirent.cpp'

We will be interested in the build flags, i.e. part

-Os -Wall -E -fpic -fshort-wchar -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mlittle-endian -mthumb-interwork

In the properties of the project, you can add your own flags, but here's a bad luck: they are all attributed to the left, and a piece
')
-fpic -fshort-wchar -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard -mlittle-endian -mthumb-interwork

generally static and always added to the right, and not a word about it in the IDE. Moreover, the "-Os" option is unchangeable in the project properties (“gray”). I will explain what happens.

• -Os - only optimizations are applied that do not increase the size of the object manager
• -fpic - build by Position Independant Code relocation model. I remind you that all the results (so-called artifacts) of the build on the Bada Toolchain are dynamic libraries (shared library). For whom this is news - you can also look at the typical <ProjectName> code Entry.cpp:
  
  

  _EXPORT_ int OspMain ( int argc, char * pArgv [ ] )

  
  If you jump on the _EXPORT_ definition, you will see (FBaseConfig.h):
  
  

  #if defined (_WIN32) // MS Compiler & MinGW GCC <br/>
  # define _EXPORT_ __declspec (dllexport) <br/>
  #elif defined (__ GNUG__) // GCC <br/>
  # define _EXPORT_ __attribute __ ((visibility ("default"))) <br/>
  #elif defined (__ ARMCC_VERSION) // ARM Compiler (RVCT 3.1) <br/>
  # define _EXPORT_ <br/>
  #else <br/>
  # define _EXPORT_ <br/>
  #endif

  
  This is me for what? So, the PIC is a reliable, but slightly slower model. Moreover, considering that in Bada all applications are in their sandboxes and cannot share common dynamic libraries - it is pointless to use PIC. Unfortunately, without this flag, the project build may fall at the linking stage of the dynamic library (and falls, I checked), because ld (performed by arm-samsung-nucleusabi-ld) cannot link in some cases, so the Koreans from Samsung stitched this flag inside. Due to a flaw in GCC 4.x, the compiler makes R_ARM_MOVW_ABS_NC reels, which binutils do not like. Now, if the assembly was using LLVM ... I got carried away with something. In general, in this situation, you can not do without -fPIC.
• -mfpu = vfpv3 - version of the floating-point model
• -mfloat-abi = hard - use only "iron" floating point operations. Generally speaking, if the code contains a floating-point function call that is not in ARM FPU, then the compilation will fail, but this is very unlikely.
• -mlittle-endian - it's unclear why, because about Cortex-A8 and so it is known that he is little endian.
• -mthumb-interwork - the ability to safely combine both ARM and Thumb code in one executable file. As you know, ARM architecture is good, among other things, because it contains a set of 16-bit Thumb instructions. The idea is that one ARM instruction occupies 32 bits, and the Thumb instruction is two times less. Total we have reduction of the size of the resulting code twice (theoretically). Practically - almost twice (there are overheads in the form of additional operations and one more thing). By default, the build runs into the ARM code, the program may not compile at all in Thumb code (who likes “optimized” assembler inserts for example? Our compilers hide such things), in the Samsung Wave firmware the Thumb code is most likely, and Koreans are reinsured. As a minus - the size of the object grows a bit due to additional pairing instructions.

So, we see the following injustice:

1. Optimization of the size of the executable file is not always preferable (especially for system, algorithmic things!)
2. mfpu = vfpv3 is, of course, good, but the cortex has NEON
3. Projects are collected in a set of instructions ARM instead of "nyashnogo" Thumb

The position of Samsung can be understood: playful hands, by changing the flags mentioned, can easily screw up the project assembly, and the Korean support service can then prove to them who they really are. However, we all know what we are doing. Can we fix the situation? Yes!

Pay attention to the file <root Bada SDK> /IDE/buildoptions.xml. There just contains a set of flags that can not be changed in the usual human way through the IDE. After editing this file, remember to restart Eclipse. Ottyagivaemsya in full:

 <comp>-fpic -mthumb -fshort-wchar -O2 -mcpu=cortex-a8 -mfpu=vfpv3 -mfloat-abi=hard</comp> 

-mthumb makes collecting Thumb code, -O2 optimizes the program normally, and now the meaningless -mthumb-interwork is removed. I checked the work with such flags on a variety of programs, and they all work as they should. I note two things:

1. If you make -mfpu = neon , applications crash when launched on the device. Why - it is not clear, I explore this moment. At work on test boards I did so many times.
2. -mthumb-interwork may still be needed in some particular cases. I ran the tests - everything works fine without it.

What do we see in the flags of the assembly on the device Bada 1.1 (line of budget Wave, like 52x)?

 <comp>-fpic -fshort-wchar -mcpu=arm9 -mfloat-abi=soft -mlittle-endian -mthumb-interwork</comp> 

First, a poor processor catches the eye, which is not written at all in the specifications on the official Samsung website, as well as -mfloat-abi = soft , because of which FPU is not used at all. The ARM9 specification on arm.com states that FPU is really optional. I don’t have these devices, and I can’t say for sure if it’s a good idea to change this flag to -mfloat-abi = softfp or -mfloat-abi = hard . But again, I recommend adding -mthumb .

I will give advice to those who have a lot of floating point calculations: add the flags -funsafe-math-optimizations -ffast-math to the project flags (in the usual way). You will not regret.

Finally, a link to all GCC flags specific to ARM .

Thank you for your attention, good development!