From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11228 invoked by alias); 19 Jul 2008 15:24:04 -0000 Received: (qmail 11208 invoked by uid 22791); 19 Jul 2008 15:24:04 -0000 X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.169) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Jul 2008 15:23:45 +0000 Received: by wf-out-1314.google.com with SMTP id 25so492717wfc.14 for ; Sat, 19 Jul 2008 08:23:41 -0700 (PDT) Received: by 10.143.17.13 with SMTP id u13mr536284wfi.18.1216481021127; Sat, 19 Jul 2008 08:23:41 -0700 (PDT) Received: by 10.143.159.20 with HTTP; Sat, 19 Jul 2008 08:23:41 -0700 (PDT) Message-ID: <74fef6df0807190823o5270be8cx22a61b7364b4ff81@mail.gmail.com> Date: Sat, 19 Jul 2008 21:37:00 -0000 From: "Mathieu Lacage" To: gcc-help@gcc.gnu.org Subject: Re: visibility and -Wl,--version-script In-Reply-To: <488162C4.85553AB4@dessent.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <74fef6df0807181837k7f0bd0a7s247a570b316ed864@mail.gmail.com> <488154A0.BB3F66BB@dessent.net> <74fef6df0807182009k49d172c7s2ec89f4321694d8d@mail.gmail.com> <488162C4.85553AB4@dessent.net> X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-07/txt/msg00234.txt.bz2 On Fri, Jul 18, 2008 at 8:43 PM, Brian Dessent wrote: > Mathieu Lacage wrote: > >> Right, but if I do that, gcc will use GOT/PLT lookups to access these >> symbols even when doing accesses from within the library and that is >> precisely what I would like to avoid. > > In that case you need to create a second alias of the symbol with hidden > visibility for internal use within the library. The Drepper paper > explains how to do this in section 2.2.7. > > The problem with doing this in C++ code is that the alias declaration > needs the assembler name of the function which includes the mangling, > and there's no way to automatically generate that short of compiling a > testcase and looking at the assembly output. You could arrange for this > to be done automatically with some kind of multi-pass compilation scheme > with tons of macro magic: first run g++ -S over the source, then use a > perl/awk/whatever script to extract the mangled names of exported > functions and substitute them back into a second compilation of the same > file with the alias declarations added. To me that sounds like a > fragile and complicated way of achieving a modest optimization. The > wrapper function approach mentioned in that same section is probably the > best way to go in the face of C++. Both options require different names to be used when calling a function internally and when calling a function through the GOT/PLT. That is clearly not something I will be able to retrofit in our codebase. So, it looks like all bets are off and that I should just build everything statically without -fpic if I want to avoid the GOT/PLT lookups. Mathieu -- Mathieu Lacage