On 02/20/2016 04:25 AM, Stephane Eranian wrote: > > > On Wed, Feb 17, 2016 at 10:27 PM, William Cohen <wco...@redhat.com > <mailto:wco...@redhat.com>> wrote: > > The shared library should only make the functions and variable visible > that are actually part of the interfaces to the outside world. > Anything that is visible to the outside could potentially be used (or > abused) by code linking with the library. Making the internal > functions and variables hidden gives more flexibility to change how the > code is implemented and improves portability. > --- > lib/pfmlib_amd64.c | 7 ++++++- > lib/pfmlib_amd64_priv.h | 5 +++++ > lib/pfmlib_arm_priv.h | 4 ++++ > lib/pfmlib_cell_priv.h | 4 ++++ > lib/pfmlib_ia64_priv.h | 5 +++++ > lib/pfmlib_intel_netburst_priv.h | 4 ++++ > lib/pfmlib_intel_snbep_unc.c | 4 ++++ > lib/pfmlib_intel_snbep_unc_priv.h | 4 ++++ > lib/pfmlib_intel_x86_perf_event.c | 4 ++++ > lib/pfmlib_intel_x86_priv.h | 4 ++++ > lib/pfmlib_itanium2_priv.h | 4 ++++ > lib/pfmlib_itanium_priv.h | 4 ++++ > lib/pfmlib_mips_priv.h | 4 ++++ > lib/pfmlib_montecito_priv.h | 4 ++++ > lib/pfmlib_powerpc_perf_event.c | 4 ++++ > lib/pfmlib_priv.h | 4 ++++ > lib/pfmlib_s390x_priv.h | 4 ++++ > lib/pfmlib_sicortex_priv.h | 6 ++++++ > lib/pfmlib_sparc_priv.h | 5 +++++ > 19 files changed, 83 insertions(+), 1 deletion(-) > > diff --git a/lib/pfmlib_amd64.c b/lib/pfmlib_amd64.c > index 1383804..0bbbee2 100644 > --- a/lib/pfmlib_amd64.c > +++ b/lib/pfmlib_amd64.c > @@ -34,6 +34,8 @@ > #include "pfmlib_priv.h" /* library private */ > #include "pfmlib_amd64_priv.h" /* architecture private */ > > +#pragma GCC visibility push(hidden) > + > > How compatible is this with LLVM/clang compilers?
Hi Stephane, I have not tried this on anything but linux and gcc. However, doing some searching around it looks like clang/llvm has some support for these attributes. There were some tests in the Clang testsuite added in 2010: https://github.com/llvm-mirror/clang/blob/master/test/CodeGenCXX/pragma-visibility.cpp This patch is a first pass at doing this and definitely would benefit from discussion. The main goal is to hide any internal data structures and functions so that other code doesn't inadvertently use them. This patch sprinkles a number of pragmas around to do that. An alternative approach would be to use the gcc compiler option to make hidden the default and explicitly make the API function/functions visible. The advantage to this would b that when support is added for a new processor implementation it would be internal and there isn't a chance for it to be externally visible. However, I don't know if clang/llvm accept the gcc -fvisibility=hidden option. -Will ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
