[cfe-dev] Inline function static variable linkage visibility issue

[Rick Taylor]

Hi All,



I have found an inconsistency between gcc and clang's handling of the linkage of static variables in visibility(hidden) member functions, when linked as shared objects.



A quick worked example:



/////////////////////////////////

/////// foo.cpp

class Foo

{

public:

      static const int* Bar()

      {

            const static int _bar[] = { 1,2,3,4 };

            return _bar;

      }

};



void __attribute__((visibility("default"))) external_fn() {

      const int* i = Foo::Bar();

}



//////////////////////////////////////





And the output from nm:



$ clang++ -fvisibility=hidden -c foo.cpp $ clang++ -shared -fvisibility=hidden foo.o -o foo $ nm -D -C foo

         w _Jv_RegisterClasses

00000480 T external_fn()

00000504 V Foo::Bar()::_bar       <-- THIS IS THE PROBLEM

0000200c A __bss_start

         w __cxa_finalize

         w __gmon_start__

0000200c A _edata

00002014 A _end

000004e8 T _fini

00000358 T _init



$ g++ -fvisibility=hidden -c foo.cpp

$ g++ -shared -fvisibility=hidden foo.o -o foo.g $ nm -D -C foo.g

         w _Jv_RegisterClasses

0000049c T external_fn()

0000200c A __bss_start

         w __cxa_finalize

         w __gmon_start__

         U __gxx_personality_v0

0000200c A _edata

00002014 A _end

000004f8 T _fini

00000380 T _init



Now I am not sure which is correct (I know there is some complex logic involved in inline member function static variables) but I am relying on the gcc linkage for the plugin layer of my project.



I have tried library sprinkling my code with __attribute__((visibility("hidden"))) on each of the static variable declarations, but that appears to make no difference, and is not required by gcc either.



Can someone more familiar with the clang codebase confirm this as a bug or my stupidity please?



Many thanks



Rick Taylor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101028/2b54e510/attachment.html>