From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13792 invoked by alias); 6 May 2004 03:21:32 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 13782 invoked by uid 48); 6 May 2004 03:21:31 -0000 Date: Thu, 06 May 2004 03:21:00 -0000 Message-ID: <20040506032131.13781.qmail@sources.redhat.com> From: "s_gccbugzilla at nedprod dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040418032536.15000.bryner@brianryner.com> References: <20040418032536.15000.bryner@brianryner.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug other/15000] Support setting the default symbol visibility for ELF X-Bugzilla-Reason: CC X-SW-Source: 2004-05/txt/msg00521.txt.bz2 List-Id: ------- Additional Comments From s_gccbugzilla at nedprod dot com 2004-05-06 03:21 ------- Please find attached merged patch of Brian's latest with all the new features I've added: -fvisibility #pragma GCC visibility -fvisibility-inlines-hidden What we don't have is nested classes inheriting the visibility setting from their enclosing classes. ANY HELP WITH THIS MUCH APPRECIATED AS I'VE GIVEN UP - I simply lack the familiarity with GCC's internals. I've left the debug printing in as it'll aid anyone trying to do the nested classes problem. I'll not post this to gcc-patches until I've done more tests here ie; building Boost.Python and my library. Another issue is how MSVC exports inlined code. It would seem that if a class is dllexport, all inlineable methods have a version of them generated and its entry made public in the export table. If it's not dllexport, it can obviously still be used outside its DLL as it'll get reinstantiated where it's used. With this patch, this behaviour is approximately emulated such that if something is marked as default visibility then it'll always appear in the export table. If not and -fvisibility=hidden is in effect, it'll get reinstantiated where it's used. I think I have this right now. A final issue is when a declaration is explicitly marked default visibility but is defined within the current compiland. Should calls to that symbol from within the current compiland skip the PLT indirection? I'm thinking probably yes, but if anyone can think of why not then I won't. This would be a breaking change with previous versions of GCC however. I've also added a test file I use to save you writing one. Best usage is to output as assembler and then you can study the assembler. Cheers, Niall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15000