×

Discussion Board

Results 1 to 5 of 5
  1. #1
    Registered User
    Join Date
    Jun 2006
    Posts
    39

    Initialization of WSD in DLL issue

    Hi

    I have a very strange issue with my DLL. In my DLL I have small amount of writeable static data, the data are initialized at declaration. When I dump the e32 image using elf2e32 --dump my static data are displayed in the .data section but are not the same as I defined them in the code. I have tested with both S60_3rd_MR and S60_3rd_FP1.

    I can easily go round this problem by either making the static data const or initialize the data at runtime. My wonder is if it is a bug in the CSL toolchain linker or if I am doing something wrong, I have read that there might be an issue with static data when using gcce, is there anyone who can confirm this or give a suggestion where to get more info about the linking process for gcce?

    Thanks
    anton

  2. #2
    Registered User
    Join Date
    Dec 2006
    Posts
    2,280

    Re: Initialization of WSD in DLL issue

    Hi,

    This is the known issue with WSD in DLLs using GCCE:
    http://www3.symbian.com/faq.nsf/AllB...2573DA0011DFA7

    It doesn't sound like the same thing that you are experiencing.

    It would depend on what type of data you are trying to initialize and how you're doing it... maybe you could post some code?

    Sorcery

  3. #3
    Registered User
    Join Date
    Jun 2006
    Posts
    39

    Re: Initialization of WSD in DLL issue

    Thanks for your answer

    It is a simple TUint32 list with initialized values

    Code:
    static TUint32 _K[] = { 1,1,1,1};
    It can easily be tested using the Symbian examples by just adding this line to PolymorphicDll1.cpp in the example located S60_3rd_MR\Examples\Base\DLLs\ will lead to that (at least for me) data section containing

    Code:
    00000001 00008029 00008619 000085e9
    The first one is correct and the other three have changed. Seems to me one can not trust the static initializations? One note on the values above is that they are related to the exported functions locations added with the initialized value, for example 8029-1=8028 which is the adress to one exported function in the DLL. If no functions are exported the data are correctly initialized.

    Could I have missed something essential about static variables or should this work?

    BR
    anton

  4. #4
    Registered User
    Join Date
    Dec 2006
    Posts
    2,280

    Re: Initialization of WSD in DLL issue

    That should work - it's almost certainly another bug in the toolchain.

    I've heard a rumor that the very latest versions of GCCE work for Symbian builds now but I haven't had any time to try it out. Of course they wouldn't be officially supported but it could be another way to work around your issue. Otherwise, just stick with your existing workaround.

    Sorcery

    P.S. Does it make a difference if you specify the size of the array in the initialization?

  5. #5
    Registered User
    Join Date
    Aug 2006
    Location
    Poland
    Posts
    36

    Re: Initialization of WSD in DLL issue

    I found the following useful information about writeable static data (WSD) and I would like to share with all my friends here :-):

    Symbian Platform Support for Writeable Static Data in DLLs
    How can I find the "uninitialised data" in my DLL?
    The post-linker (elf2e32) will warn you if your DLL contains uninitialised data when you build for the device:

    elf2e32 : Error: E1028: ELF File \...\DllWithStaticData.dll contains uninitialized writable data.
    The Symbian platform allows global writeable static data (WSD) for DLLS that have EPOCALLOWDLLDATA in their MMP file. As there are costs associated with the use of WSD, this error is raised to catch the case of accidental usage. Note that the compilers used for Emulator builds tend to create 'accidental' WSD even when it is not explicitly required by the DLL code : therefore this error is not raised on Emulator builds.

    Consider this section of C++ code, added to a file QSORT.CPP which is part of ESTLIB.DLL.
    // variables
    struct div_t uninitialised1; // in .BSS
    static struct div_t uninitialised2; // in .BSS
    struct div_t initialised1 = {1,1}; // in .DATA
    static struct div_t initialised2 = {2,2}; // in .DATA

    // constants
    const struct div_t const1 = {3,3};
    const static struct div_t const2 = {4,4};
    const TPoint none(-1,-1);
    static const TText* plpPduName[12] =
    {_S("Invalid"), _S("DataFlowOff"), _S("DataFlowOn"),
    _S("ConnectRequest"), _S("ConnectResponse"), _S("ChannelClose"),
    _S("Info"), _S("ChannelDisconnect"), _S("End"), _S("Delta"),
    _S("EndOfWrite"), _S("PartialWrite")};

    The associated .MAP file contains information which helps to track down the source file involved. Look in epoc32\release\gcce\urel\dllname.dll.map in sections ".data" or ".bss"
    In this example, we find:

    .data 0x10017000 0x2000
    x10017000 __data_start__=.
    *(.data)
    .data 0x10017000 0x40 ..\..\EPOC32\BUILD\STDLIB\BMMP\ESTLIB\ARM4\UREL\ESTLIB.in(QSORT.o)
    0x10017000 initialised1
    *(.data2)
    *(SORT(.data$*))
    0x10017040 __data_end__=.
    *(.data_cygwin_nocopy)

    .bss 0x10018000 0x18
    0x10018000 __bss_start__=.
    *(.bss)
    .bss 0x10018000 0x18 ..\..\EPOC32\BUILD\STDLIB\BMMP\ESTLIB\ARM4\UREL\ESTLIB.in(QSORT.o)
    0x10018008 uninitialised1
    *(COMMON)
    0x10018018 __bss_end__=.

    So the DLL has 0x18 bytes of uninitialised data (.BSS) and 0x40 bytes of initialised data (.DATA), all of which comes from QSORT.o The variables "initialised1" and "uninitialised1" both have global scope, so the MAP file lists them by name. The static variables don't get named in the .MAP file.

    Removing the first four lines of code shown above leaves just variables which are declared as const, but only reduces the .BSS to 0x08 bytes and the .DATA to 0x30 bytes. There are two problems remaining:

    Declaring C++ objects as const doesn't help if they have a constructor (see [#Don't be misled by const static data that isn't really const]). The 8 bytes of uninitialised data are allocated to hold the TPoint object, but it won't become const until after the constructor has been run.

    The declaration const TText* says that the TText values may not be altered, but it doesn't make the pointer a constant as well. The 48 bytes of initialised data are the 12 pointers in the plpPduName array. To make the pointers constant as well as the values they point to, the declaration needs and additional const after the TText*.

    static const TText* const plpPduName[12] ={_S("Invalid"), _S("DataFlowOff"), _S("DataFlowOn"),
    _S("ConnectRequest"), _S("ConnectResponse"), _S("ChannelClose"),_S("Info"), _S("ChannelDisconnect"),
    _S("End"), _S("Delta"), _S("EndOfWrite"), _S("PartialWrite")};

    Removing the TPoint global variable and adding the extra const to the plpPduName array finally removes the last of the offending .BSS and .DATA.
    Thank you,
    Mido

Similar Threads

  1. GoogleIt
    By deepika.mangla in forum Symbian
    Replies: 5
    Last Post: 2011-05-28, 11:04
  2. static dll initialization problem?
    By donDonald in forum Symbian
    Replies: 2
    Last Post: 2007-02-26, 11:00
  3. Replies: 3
    Last Post: 2005-04-11, 20:00
  4. Replies: 0
    Last Post: 2003-03-14, 08:43
  5. can not successfully link any sample using .NET
    By lobotomat in forum Symbian Tools & SDKs
    Replies: 2
    Last Post: 2002-08-20, 00:29

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×