From mattes@azu.informatik.uni-stuttgart.de Sat Sep 17 14:24:54 2005 From: Eberhard Mattes Subject: Creating DLLs with global writable data (yes, it can be done!) Date: 27 Aug 2001 11:11:11 UTC Organization: what? Message-ID: <5IDyvyuLBHA.1300@extapps30> Newsgroups: discussion.epoc.C++ Lines: 148 Path: extapps30 Xref: extapps30 discussion.epoc.c++:6691 NNTP-Posting-Host: tesla.iema.uni-stuttgart.de 129.69.178.1 How often has Symbian told us that EPOC does not and cannot support DLLs (except in ROM) which have global writable data? No matter how often Symbian claims that, it isn't true -- EPOC has explicit support for DLLs with global data. Before I tell you how to create DLLs with global data, let me explain the drawbacks and restrictions: - the data is shared by all threads of the process (well, it's *global* data); if you need thread-local data, use Dll::Tls() instead - only up to 256 DLLs (per process) can have global data as the virtual address space reserved for global DLL data encompasses 256 MB and the minimum chunk size is 1 MB, that is, there are 256 distinct addresses at which the global data section can start - this is the major restriction: the address at which global data starts (apparently) must be hardcoded; no two DLLs (per process) can have global data at the same address The last restriction is quite serious and is probably the reason for Symbian not telling us how to create DLLs with global data. (But they have made and distributed at least one DLL, javai.dll, which uses global data!) To avoid conflicts between DLLs, a DLL with global data should only be made if there's no better solution and if usage of that DLL is restricted to your own programmes; DLLs for use by arbitrary programmes (by other developers) should never have global data. If everyone follows that rule, no conflicts should arise. BTW, that serious restriction is a gratuitous one: EPOC DLLs contain enough relocation information to enable relocation of the global data section to an available slot, but EPOC apparently doesn't bother. Enough preliminaries, here's how to create a DLL with global writable data (tested under ER5 only): (1) choose a virtual address for the DLL's global data; the address must be a multiple of 1 MB and must be between 0x30000000 and 0x3ff0000, inclusive; remember that data of no two DLLs used by one programme can overlap, therefore you have to choose a unique address for each DLL used by your programme (2) in E32Dll(), call Dll::InitialiseData() when a process attaches and Dll::FreeData() when a process detaches; see sample code below (3) at link/petran time, put the data section at the address chosen in step (1). Don't ask me how to do this with the Symbian SDK -- I use my own build tools where creating a DLL with global data is as simple as: arm-epoc-pe-gcc -o data.dll -shared data.cc -Zimplib data.lib \ -Tdata 0x30000000 -uid3 0x01234567 (-Tdata 0x30000000 automatically selects -allowdlldata; the import library data.lib will be created.) That's all. It's also possible to export data from such a DLL by defining symbols in the absolute section (taking advantage of the DLL's data being at a fixed address): arm-epoc-pe-gcc -o data.dll -shared data.cc -Zimplib data.lib \ -Tdata 0x30000000 -uid3 0x01234567 \ -Zexportdata data.dex In this example, the text file data.dex supplies the names of the variables to be exported. Note that exporting data this way is very fragile as the EXE directly uses hardcoded addresses of data in the DLL; achieving binary compatibility is difficult, but that should not be a problem if EXE and DLL are coupled tightly as recommended above. Constant data (in .text or .rdata) cannot be exported that way, but you can export a pointer (in .data) to constant data. Here's sample code: ---------------------------------------------------------------------- TInt E32Dll (TDllReason aReason) { if (aReason == EDllProcessAttach) return Dll::InitialiseData (); else if (aReason == EDllProcessDetach) Dll::FreeData (); return KErrNone; } ---------------------------------------------------------------------- Please don't misuse this technique! On ARM CPUs, using a pointer to global data is more efficient than using global data anyway. Still use const to avoid duplication of data in each process which uses the DLL! And now for other things Symbian does not want to tell or give us: - There's a file named dd.chm available for download from www.symbiandevnet.com (even for non-paying developers), containing the documentation for developing device drivers for ER5. However, the header files and libraries are nowhere to be found and Symbian claims that there's no DDK. What's the point of having the documentation if it's impossible to obtain the headers and libraries? Teasing? "See!" - sysdoc/cpp/wserv/wssys.html of the ER5 C++ SDK says: "The following logging DLLs are supplied with the EPOC C++ SDK: [...] - dlogfl.dll - for logging to file, installed in \epoc32\release\wins\variant\ and in \epoc32\release\marm\rel\ (for a target machine). - dlogsr.dll - for logging to the serial port, installed in \epoc32\release\marm\rel\ (for a target machine only)." Those files are nowhere to be found. - sysdoc/cpp/stdlib/slimplem.html of the ER5 C++ SDK says: "In the next release, due in the first half of 1998, STDLIB will provide some support for POSIX process creation, environment variable inheritance, and inter-process communication using pipes." Perhaps this alludes to popen3(), but that function is completely undocumented. - FAQ-0187 in the knowledge base talks about a Spy tool and says that the WINS version is part of the C++ and OPL SDKs. I couldn't find it (but then, I don't use the "emulator" anyway). The MARM version "is available for download from the Members' area of the EPOc world Web site". For *paying* members only? Let's share what we find out about EPOC's dark corners. -- Eberhard Mattes