http://d.puremagic.com/issues/show_bug.cgi?id=7319

           Summary: .bss section not used
           Product: D
           Version: D2
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: Marco.Leise@gmx.de


--- Comment #0 from Marco Leise <Marco.Leise@gmx.de> 2012-01-19 05:10:25 PST ---
Consider this struct definition:

    struct Test1 {
        byte arr[1024 * 1024 * 10];
    }

DMD for Windows places 10 MB into the BSS section, whereas DMD on Linux fails to use the equivalent .bss section.

This is not always the case, as this declaration shows:

    struct Test2 {
        __gshared byte arr[1024 * 1024 * 10];
    }

Now the struct is correctly placed inside .bss. But this can easily lead to bad runtime behavior, as the last test case shows:

    struct Test {
        byte arr1[1024 * 1024 * 10];
        __gshared byte arr2[1024 * 1024 * 10];
    }

    int main() {
        Test test;
        return 0;
    }

This will SEGFAULT when the stack variable test is about to be initialized.

Other observations:
- Placing the array outside the struct, directly at module level results in a
small executable size. (It probably uses .tbss here correctly for thread local
storage?)
- This and the above tests can be reproduced with GDC as well, so I assume the
bug is at the front-end stage.
- How is MacOSX affected ?
- What is the scope of __gshared, what can be attributed with it?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7319


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #1 from Jacob Carlborg <doob@me.com> 2012-01-19 06:24:00 PST ---
On Mac OS X it will result in a 10.7 MB executable when "__gshared" is not used.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7319



--- Comment #2 from Marco Leise <Marco.Leise@gmx.de> 2012-01-19 07:18:03 PST ---
My personal 'fix' is to use this code - adapted from the Windows section in toobj.c:

    #if ELFOBJ
        if (sinit->Sdt &&
            sinit->Sdt->dt == DT_azeros &&
            sinit->Sdt->DTnext == NULL &&
            !global.params.multiobj)
        {
            sinit->Sseg = UDATA;
        }
        else
        {
            sinit->Sseg = CDATA;
        }
    #endif

It seems to work with the dmd Makefile for Phobos/druntime itself and on my own program. I don't know the compiler source code, but from what I read briefly, "global.params.multiobj" means: compile to single .obj/.o files. If so, then this would effect unity builds only (?)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7319



--- Comment #3 from Jacob Carlborg <doob@me.com> 2012-01-19 08:08:49 PST ---
It needs a fix for Mac OS X as well.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7319


Marco Leise <Marco.Leise@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------