digitalmars.D.bugs - [Issue 7319] New: .bss section not used
- d-bugmail puremagic.com (45/45) Jan 19 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7319
- d-bugmail puremagic.com (11/11) Jan 19 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7319
- d-bugmail puremagic.com (24/24) Jan 19 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7319
- d-bugmail puremagic.com (6/6) Jan 19 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7319
- d-bugmail puremagic.com (8/8) Feb 29 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7319
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 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: -------
Jan 19 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7319 Jacob Carlborg <doob me.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |doob me.com 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: -------
Jan 19 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7319 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: -------
Jan 19 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7319 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: -------
Jan 19 2012
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: -------
Feb 29 2012