From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24718 invoked by alias); 26 May 2012 23:56:26 -0000 Received: (qmail 24710 invoked by uid 22791); 26 May 2012 23:56:25 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SINGLE_HEADER_2K X-Spam-Check-By: sourceware.org Received: from mail-qc0-f175.google.com (HELO mail-qc0-f175.google.com) (209.85.216.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 May 2012 23:56:09 +0000 Received: by qcso7 with SMTP id o7so1169761qcs.20 for ; Sat, 26 May 2012 16:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.136.21 with SMTP id p21mr784694qct.121.1338076568445; Sat, 26 May 2012 16:56:08 -0700 (PDT) Received: by 10.229.169.130 with HTTP; Sat, 26 May 2012 16:56:08 -0700 (PDT) In-Reply-To: References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> Date: Sat, 26 May 2012 23:56:00 -0000 Message-ID: Subject: Re: User directed Function Multiversioning via Function Overloading (issue5752064) From: "H.J. Lu" To: Sriraman Tallam Cc: Xinliang David Li , Richard Guenther , Jan Hubicka , Uros Bizjak , reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org, Ian Lance Taylor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg01811.txt.bz2 On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam wrot= e: > On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote: >> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam w= rote: >>> >>> On May 25, 2012 7:15 PM, "H.J. Lu" wrote: >>>> >>>> >>>> On May 25, 2012 6:54 PM, "Sriraman Tallam" wrote: >>>> > >>>> > >>>> > >> >>>> > >> On Fri, May 25, 2012 at 5:0 > > BTW, I noticed: >>>> >>>> > > >>>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep __cpu_model >>>> > > =A0 =A020: 0000000000000010 =A0 =A016 OBJECT =A0GLOBAL HIDDEN =A0 = COM __cpu_model >>>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so | grep __cpu_model >>>> > > =A0 =A082: 0000000000214ff0 =A0 =A016 OBJECT =A0GLOBAL DEFAULT =A0= 24 >>>> > > __cpu_model@@GCC_4.8.0 >>>> > > =A0 310: 0000000000214ff0 =A0 =A016 OBJECT =A0GLOBAL DEFAULT =A0 2= 4 __cpu_model >>>> > > [hjl@gnu-6 pr14170]$ >>>> > > >>>> > > Why is __cpu_model in both libgcc.a and libgcc_s.o? >>>> > >>>> > How do I disallow this in libgcc_s.so? Looks like t-cpuinfo file is >>>> > wrong but I cannot figure out the fix. >>>> > >>>> Why don't you want it in libgcc_s.so? >>> >>> I thought libgcc.a is always linked in for static and dynamic builds. So >>> having it in libgcc_s.so is redundant. >>> >> >> [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep _cpu_ >> =A0 =A020: 0000000000000010 =A0 =A016 OBJECT =A0GLOBAL HIDDEN =A0 COM __= cpu_model >> =A0 =A021: 0000000000000110 =A0 612 FUNC =A0 =A0GLOBAL HIDDEN =A0 =A0 4 = __cpu_indicator_init >> [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so.1 | grep _cpu_ >> =A0 =A082: 0000000000214ff0 =A0 =A016 OBJECT =A0GLOBAL DEFAULT =A0 24 >> __cpu_model@@GCC_4.8.0 >> =A0 223: 0000000000002b60 =A0 560 FUNC =A0 =A0LOCAL =A0DEFAULT =A0 11 __= cpu_indicator_init >> =A0 310: 0000000000214ff0 =A0 =A016 OBJECT =A0GLOBAL DEFAULT =A0 24 __cp= u_model >> [hjl@gnu-6 pr14170]$ >> >> I think there should be only one copy of __cpu_model in the process. >> It should be in libgcc_s.so. Why isn't =A0__cpu_indicator_init exported >> from libgcc_s.so? > > Ok, I am elaborating so that I understand the issue clearly. > > The dynamic symbol table of libgcc_s.so: > > $ objdump -T libgcc_s.so | grep __cpu > > 0000000000015fd0 g =A0 =A0DO .bss =A0 0000000000000010 =A0GCC_4.8.0 =A0 _= _cpu_model > > It only has __cpu_model, not __cpu_indicator_init just like you > pointed out. I will fix this by adding a versioned symbol of > __cpu_indicator_init to the *.ver files. That will be great. > Do you see any other issues here? I dont get the duplicate entries > part you are referring to. The static symbol table also contains > references to __cpu_model and __cpu_indicator_init, but that is > expected right? Duplication comes from static and dynamic symbol tables. > In libgcc.a: > > readelf -sWt /g/tmsriram/GCC_trunk_svn_mv_fe_at_nfs/native_builds/bld1/in= stall/lib/gcc/x86_64-unknown-linux-gnu/libgcc.a > | grep __cpu > > =A0 20: 0000000000000010 =A0 =A016 OBJECT =A0GLOBAL HIDDEN =A0COM __cpu_m= odel > =A0 =A021: 0000000000000110 =A0 612 FUNC =A0 =A0GLOBAL HIDDEN =A0 =A04 __= cpu_indicator_init > > libgcc.a has __cpu_model and __cpu_indicator_init as GLOBAL syms with > HIDDEN visibility. Is this an issue? Is this not needed for static > linking? > > Further thoughts: > > * It looks like libgcc.a is always linked for both static and dynamic > links. It occurred to me when you brought this up. So, I thought why > not exclude the symbols from libgcc_s.so! Is there any problem here? > You don't want one copy of those 2 symbols in each DSO where they are used. --=20 H.J.