digitalmars.D.bugs - [Issue 7083] New: variables with static/private storage create global symbols
- d-bugmail puremagic.com (48/48) Dec 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7083
- d-bugmail puremagic.com (14/14) Dec 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7083
- d-bugmail puremagic.com (8/9) Mar 27 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7083
- d-bugmail puremagic.com (10/13) Apr 03 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7083
http://d.puremagic.com/issues/show_bug.cgi?id=7083 Summary: variables with static/private storage create global symbols Product: D Version: D2 Platform: Other OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: dawg dawgfoto.de ---- module bug; static { __gshared int sa; extern(C) __gshared int sb; } private { __gshared int pa; extern(C) __gshared int pb; } ---- dmd -c bug.d nm -c bug.o output: 0000000000000008 B _D3bug2pai 0000000000000000 B _D3bug2sai 000000000000000c B pb 0000000000000004 B sb expected output: 0000000000000008 b _D3bug2pai 0000000000000000 b _D3bug2sai 000000000000000c b pb 0000000000000004 b sb ---------------- Either static or private should provide the C's static semantic of defining a local symbol, i.e. one that can only be accessed from within the same object file. Probably only useful for extern(C) as D declarations are scoped by the mangling but for D it would still shrink the symbol table. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 08 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7083 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |WONTFIX 20:56:19 PST --- This is done deliberately as the code/data for one module can be distributed among several object files (unlike C) and the only way they can communicate is via a global name. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 08 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7083 It would be good to reconsider this for PIC code where every access to global symbols is indirect through the GOT table.as the code/data for one module can be distributed among several object filesDo you mean the multilib support? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 27 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7083It would be good to reconsider this for PIC code where every access to global symbols is indirect through the GOT table.This could be achieved by changing the default visibility to hidden. Similar to Windows only symbols with the export attribute would be visible in a shared library thus allowing link-time optimizations for non-exported symbols. http://gcc.gnu.org/wiki/Visibility -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 03 2013