Unique ARM platform issues writable static data in DLLs

Http://hi.baidu.com/hijzhang/blog/item/b6d5bf24b44d41318744f983.html [s60] ARM platform exclusive issues writable static data in DLLs2007-07-08

When compiling the ARM platform program, the following error message is displayed: Error: DLL 'appname [uid]. app' has initialised data. Or: Error: DLL 'appname [uid]. app' has uninitialised data. (The application with the extension app is actually a DLL .) This problem does not occur when compiling the simulator. This once led me to complete the design, encoding, and debugging, Forced to abandon the original design. The literal meaning of this error message cannot be seen.Initialised andUninitialised has the same problem. The real meaning is that the dll contains writable global variables. We know that when the program is running, the DLL will only be loaded once. On Windows, each process has its own DLL space. That is to say, different processes load the same DLL and are independent of each other. It is shared only within one process. However, the s60 platform is designed to allow all processes to share the same DLL space. This design is obviously out of memory savings and is necessary. However, this poses a problem, that is, the DLL cannot contain writable global variables, otherwise it will cause confusion. Modifying the variables of process a directly affects process B, which is not expected by the program designer. Therefore, the compiler of the s60 platform prohibits the declaration of writable global variables in the DLL. However, global variables can still be used, as long as the const statement is added. Generally, you are not encouraged to use writable global variables when designing DLL. Even on Windows, the writable global variables of DLL may cause problems between different modules. When this compiler error occurs, try to modify the design and avoid using global variables. However, because the app is actually a DLL, even the s60 main program cannot use writable global variables, which sometimes becomes a problem, global variables are an important means of implementation. In this regard, s60 provides local thread storage (Thread Local Storage) To solve the problem. Two functions are critical to TLS: Void dll: settls (void *) andVoid * dll: TLS () Settls is used to save any type of pointer to the local storage of the thread, and TLS () extracts the pointer. The Pointer Points to a memory allocated on the heap. A thread can have only one local storage variable. Therefore, if you have many global variables, You need to define a structure and encapsulate all global variables in it. This is quite awkward, but s60 3rd is said to support DLL writable global variables. TLS sample code: Set Globaldata * P = new globaldata (); If (P) { DLL: settls (P ); } Use Globaldata * P = (globaldata *) dll: TLS ();     Supplement:   Writable static data Global writeable static data (WSD)Is the pre-processing variable that exists throughout the lifecycle of the process. Sometimes we need WSD to define variables for other files. This often happens when the code of the non-Symbian operating system environment is transplanted to the Symbian system.   WSD on eka1 In kernel architecture eka1 of Symbian 6.1, 7.0, 7.0 S, 8.0a, and 8.1a, only WSD is supported in EXE programs. We cannot use WSD in DLL and App. If we make such a definition, the compiler will report the "initialize data" error message. In eka1, if we want to use WSD, we have the following solutions: (1) Use local thread storage (TLS, thread local storage ). InFAQ and technical skills of SymbianHere is an example about how to use TLS to define WSD. (2) convert global variables into class member variables. This method requires a lot of work, especially when WSD is used in many different places. (3) Use ecompxl. Although ecompxl is used to compress executable program files of the Symbian system, its "side effect" allows developers to use it as WSD. WSD on eka2 In the kernel versions 8.0b, 8.1b, and later versions of Symbian, both EXE and DLL support WSD. However, using WSD in DLL still requires some minor modifications. You need to add the following macro definition in the matrix file: Epocallowdlldata However, there is a price. When using WSD on eka2, consider the following situations: (1) On the simulator of eka2, only wsd dll files can be loaded by one process. (This problem has been encountered in the recent project. a wsd dll is called by two EXE files, so the two EXE files cannot be switched to each other, prompting feature. Not supported, haha ~~) (2) WSD data blocks occupy Ram Space (3) block on armv5 is a limited resource. (4) The number of wsd dll files in a process is limited.