Introduction
The Symbian operating system does not support the use of writable static data in DLL's. This can be a major problem if your application uses global variables.
There are a number of quick tricks that can be used in the Symbian tool chain to fix this problem quickly and easily. So whilst your application may build and run without problems on the emulator, it will fail to build using the ARM chipsets. Typically the error you will see will be
“ERROR: Dll ‘(null)'” has initialised data”
Symbian do a good job of explaining why the error occurs in FAQ-0329, however they unfortunately left out how to find out which variable(s) is/are causing this error.
Finding uninitialized data
As with most things identifying you have a problem with non-const data is easy, you will find
that your DLL does not build. Fixing it is harder however.
Below are the steps that need to be taken to identify and then isolate the offending variables
in the source code.
Configuring your Project
A little used feature of the mmp file format is the OPTION command. In this case we use it to tell the Tool Chain that we want to add to the build flags for GCC compiler.
This option avoids either patching the perl script (ugly) or patching the generated make file from abld which are
overwritten each time the build process is triggered.
The MMP file will need to be changed and the line below added to the top of the mmp file, after the UID declaration.
OPTION GCC -save-temps.
This line will add thus the “-save-temps” configuration to the GCC make file when it is built using the bldmake/makmake process. This command informs GCC to save the intermediate files that it generated so that it can be used later to see what went wrong. In our case it holds lots of clues about where we can find the static data that should not be there.
The project can now be regenerated using the BLDMAKE or MAKMAKE programs in the Symbian tool chain. Once
these have been run and the make file created, it can be built.
During the build process a warning may be displayed “Warning: -pipe ignored since -save-temps specified” This message can safely be ignored as it is just indicating that we have overridden a GCC option.
Identifying the Writeable Data
By adding the “-save-temps” command to the compiler command line, this will generate a “.i” and a “.s” file in the directory where abld was created, this is normally the same directory as your bld.inf file.
If you are a command line wiz you can use grep command to find out which files have a “.data” and/or a “.bss” section in them. Alternatively just use the find in files functionality that is in most IDE's to search the project directory (i.e. the bld.inf directory) for all files the have an extension of “.s” and contain the phrase “.bss” or “.data” “.bss” is the uninitinalized data section
“.data” is the initialized data section. It is now a simple case of finding all the files with a .bss or a .data section in them, locating them in the “.s” file and then finding out the variable associated with the section.
Appropriate action can then be taken to fix the problem with the writable data.
A Short Example
This bit of code itself is very simple:
static unsigned char UnInitializeData[4];
static char* NonConstData[1] = NULL;
We have two declarations for the variables, either one of which will cause build problems.
First you will need to comment out all the lines. Next, uncomment NoConstData and see that it generates a DLL has initialized data error in linking.
Next, comment out the NonConstData line and uncomment the UnInitializedData line and see that it generates a DLL has Uninitialized data error. Make sure both the lines are uncommented and do a build.
You will get errors. Open the generated “StaticData.s” file and search for the “.bss” string
which is the uninitialised data section. You will see the intermediate code as below:
@ Generated by gcc 2.9-psion-98r2(Symbian build 542) for ARM/pe
.file "Staticdata.cpp"
.gcc2_compiled.:
.section .rdata
.align 0
.LC0:
.ascii "test\000"
.data
.align 0
NonConstData:
.word .LC0
.text
.align 0
.global E32Dll__F10TDllReason
E32Dll__F10TDllReason:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, current_function_anonymous_args = 0
mov r0, #0
mov pc,
lr
.bss
UnInitializeData: .space 4
The .data and .bss data sections are the variables that have writeable data, in this case it is both initialized and uninitialized data.
Fixing both these so that they are const and initialized will make the DLL build correctly
Acknowlegements
I would also like to extend my thanks to Simon Woodside who showed the -save-temps trick in GCC on his blog.
There is an error when i try to compile. Unrecognize Keyword "OPTION".
How do i resolve this?
Did you put the option key word in the mmp, and then regenerate the build files using bldmake/makmake?
What version of symbian are you using?
Does this method work for the UiQ builds ?
I cannot find any .s or .i file after the builds.
thanks Drew
I did all the testing on the UIQ toolchain as this is my primary developer platform.
Did you run makmake or bldmake and then a full rebuild using abld?
Did you search you harddrive for any of those file types?
Hi, thanks for the article!
I used this method with Metrowerks CodeWarrior: In Targets, selected settings for ARMI UDEB and added "-save-temps" to Code Generation / Symbian Compiler / Arguments.
The .s-files were generated to epoc32\gcc\bin\
There is a simpler method to find the problematic variables (using "nm" utility provided with GCC). I created a simple batch file to find the modifiable statics:
rem ------ start of find_statics.bat ------
@echo off
for /R %%f in (*.o) do ( echo %%f & nm %%f > tmp.txt & find /I " d " < tmp.txt & find /I " b " < tmp.txt & find /I " g " < tmp.txt )
del /f tmp.txt 2> NULL:
rem ------ end of find_statics.bat ------
(Please note that it uses MSWin2K/XP CMD.EXE with Command Extensions enabled. And, of course, it is possible to write much more elegant script using UNIXish utilities :-).
Well, just copy the lines above to, say, find_statics.bat, go to BUILD directory of you application/DLL, and run the batch, e.g.
c:\> cd c:\Symbian\7.0s\Series60_v21\Epoc32\BUILD\MY_APP\GROUP
c:\Symbian\7.0s\Series60_v21\Epoc32\BUILD\MY_APP\GROUP> find_statics.bat
The result will be something like:
c:\Symbian\7.0s\Series60_v21\Epoc32\BUILD\MY_APP\GROUP\MY_APP\THUMB\UREL\GOOD1.o
c:\Symbian\7.0s\Series60_v21\Epoc32\BUILD\MY_APP\GROUP\MY_APP\THUMB\UREL\BAD.o
00000008 d PROBLEMATIC_VARIABLE1
00000004 d PROBLEM_VAR2
c:\Symbian\7.0s\Series60_v21\Epoc32\BUILD\MY_APP\GROUP\MY_APP\THUMB\UREL\GOOD2.o
Good luck!
Yes, this batch file is much better than the method proposed by the orignal post. I tried both and this one helped me to find my problem. And it is much faster.
Thanks Ray