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


--- Comment #0 from dawg@dawgfoto.de 2011-12-08 17:28:27 PST ---
----
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: -------

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


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2011-12-08 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: -------

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



--- Comment #2 from Martin Nowak <code@dawg.eu> 2013-03-27 13:07:58 PDT ---
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 files

Do you mean the multilib support?

-- 
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=7083



--- Comment #3 from Martin Nowak <code@dawg.eu> 2013-04-03 19:55:13 PDT ---
(In reply to comment #2)
> It 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: -------