Static functions

David Leimbach leimy2k at mac.com
Mon Jan 12 16:53:16 GMT 2004


On Jan 12, 2004, at 10:00 AM, Thiago Macieira wrote:

> Bo Thorsen wrote:
>> I don't "feel" anything about it - if the symbols are gone from the
>> symbol table, then that's all good. But I don't believe so, the file
>> static functions are necessary to achieve this. Prove me wrong :-)
>
> You are right. Simple testing reveals:
>

Oops... yep.  Anonymous namespaces still have external linkage but
no way to get at the goodies :).

It's only half as strong as a static symbol then.  And the KDE macros
listed below do the correct stuff for gcc anyway.  What about other 
compilers?

I think Intel tries to be compatible with gcc attributes but I haven't 
verified this
independently.


> $ cat test.cpp
> int v1;
> static int v2;
>
> namespace
> {
>   int v3;
>   static int v4;
> };
>
> main()
> {
> }
> $ nm -C test.o
> 00000008 B (anonymous namespace)::v3
> 0000000c b (anonymous namespace)::v4
> 00000000 T main
> 00000000 B v1
> 00000004 b v2
> $ readelf -s test.o
>
> Symbol table '.symtab' contains 11 entries:
>    Num:    Value  Size Type    Bind   Vis      Ndx Name
>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
>      1: 00000000     0 FILE    LOCAL  DEFAULT  ABS test.cpp
>      2: 00000000     0 SECTION LOCAL  DEFAULT    1
>      3: 00000000     0 SECTION LOCAL  DEFAULT    2
>      4: 00000000     0 SECTION LOCAL  DEFAULT    3
>      5: 00000004     4 OBJECT  LOCAL  DEFAULT    3 v2
>      6: 0000000c     4 OBJECT  LOCAL  DEFAULT    3
> _ZN13_GLOBAL__N_v12v4E
>      7: 00000000     0 SECTION LOCAL  DEFAULT    4
>      8: 00000000     4 OBJECT  GLOBAL DEFAULT    3 v1
>      9: 00000008     4 OBJECT  GLOBAL DEFAULT    3
> _ZN13_GLOBAL__N_v12v3E
>     10: 00000000    23 FUNC    GLOBAL DEFAULT    1 main
>
>
> Note how 'v2' and  'v4' have a type of 'b' (meaning local .bss), while
> 'v1' and 'v3' are 'B' (global .bss). The readelf output also reveals
> that there are three globally-exported symbols: v1, main and one
> C++-mangled symbol ending in 'v3'.
>
> Using a neat trick of gcc extension in ELF targets, we get more:
> $ cat test.cpp
> int v5 __attribute__((visibility("hidden")));
> int v6 __attribute__((visibility("protected")));
> int v7 __attribute__((visibility("internal")));
>
> main()
> { }
> $ nm test | grep 'v[567]$'
> 080494e4 B v5
> 080494e8 B v6
> 080494ec B v7
> $ readelf -s test | grep 'v[567]$'
>     44: 080494e8     4 OBJECT  GLOBAL PROTECTED   22 v6
>     49: 080494ec     4 OBJECT  GLOBAL INTERNAL   22 v7
>     61: 080494e4     4 OBJECT  GLOBAL HIDDEN   22 v5
>
> $ nm test.so | grep 'v[567]$'
> 00001724 b v5
> 00001728 B v6
> 0000172c b v7
> $ readelf -s test.so | grep 'v[567]$'
>     22: 00001728     4 OBJECT  GLOBAL PROTECTED   19 v6
>     41: 0000172c     4 OBJECT  LOCAL  INTERNAL   19 v7
>     42: 00001724     4 OBJECT  LOCAL  HIDDEN   19 v5
>     44: 00001728     4 OBJECT  GLOBAL PROTECTED   19 v6
>
> And here comes the fun part: there are macros for those defined in
> kdemacros.h:
> #define KDE_NO_EXPORT __attribute__ ((visibility("hidden")))
> #define KDE_EXPORT __attribute__ ((visibility("visible")))
> #define KDE_PACKED __attribute__((__packed__))
> # define KDE_DEPRECATED __attribute__ ((deprecated))
>
> So we just have to use what we already have.
>
> -- 
>   Thiago Macieira  -  Registered Linux user #65028
>    thiagom (AT) mail (dot) com
>     ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
>     E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358





More information about the kde-core-devel mailing list