www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7083] New: variables with static/private storage create global symbols

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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 files


Do 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
prev sibling parent d-bugmail puremagic.com writes:
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.
 


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