From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31380 invoked by alias); 27 May 2012 00:24:05 -0000 Received: (qmail 31366 invoked by uid 22791); 27 May 2012 00:24:03 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SINGLE_HEADER_2K,TW_BJ,TW_LG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 May 2012 00:23:49 +0000 Received: by obhx4 with SMTP id x4so3660670obh.20 for ; Sat, 26 May 2012 17:23:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=U+/mGvkF3uMJQt9PIDD6KpTIqZCI3yvkxX94NNzTOT4=; b=X+j6pF5wn30ph4wLCHZR4dsnXLRH0SPZz5Hxd7gHhdzDffeLf0lKtyQ+buDyvxwrS0 P65cJkWI7n1Oq8cCrtl0oVJjYMkchGXFY5ugFJzrgvp0cLRDZ9FtMALciSK2JCbBx2au jJnct8vnWV7k73ck8IAv42cRyNpoSG5szxCBySxEiIWF6U7Y3VPrX+/fVrGu3IM9r/uw J1K5ewjIQ4QUtlRZeCEh7AfFq2DtGx4Po2Lb7pxAG540ae+KjymZj2rp0z+dkV9Oc62W U5b5lSMOWDr5L0H9ctgDTd7JxkdYx7BC+TV4CJNKYidBviDFa1KIZrGPuZp9uO+HpxBM UeNQ== Received: by 10.182.151.113 with SMTP id up17mr3571439obb.40.1338078228944; Sat, 26 May 2012 17:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.151.113 with SMTP id up17mr3571424obb.40.1338078228753; Sat, 26 May 2012 17:23:48 -0700 (PDT) Received: by 10.182.101.202 with HTTP; Sat, 26 May 2012 17:23:48 -0700 (PDT) In-Reply-To: References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> Date: Sun, 27 May 2012 00:24:00 -0000 Message-ID: Subject: Re: User directed Function Multiversioning via Function Overloading (issue5752064) From: Sriraman Tallam To: "H.J. Lu" 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-System-Of-Record: true X-Gm-Message-State: ALoCoQm96NnXJQc/srQpXey+JLEkQlPZpFJV0FVY9qvNBGQMZGKPyGKcMjFDPmOBxKY6NT2/2WCNJ+z144VgAu5s3H+UWG/3FZrrlo79k1mVyAd3C3K6epumIhRUHWRDQvWbflTB+n6yOvFYcvHLXYseIX/Rf5QM5w== 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/msg01812.txt.bz2 On Sat, May 26, 2012 at 4:56 PM, H.J. Lu wrote: > On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam wr= ote: >> On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote: >>> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam = wrote: >>>> >>>> On May 25, 2012 7:15 PM, "H.J. Lu" wrote: >>>>> >>>>> >>>>> On May 25, 2012 6:54 PM, "Sriraman Tallam" wrot= e: >>>>> > >>>>> > >>>>> > >> >>>>> > >> 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 = 24 __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 __c= pu_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/i= nstall/lib/gcc/x86_64-unknown-linux-gnu/libgcc.a >> | grep __cpu >> >> =A0 20: 0000000000000010 =A0 =A016 OBJECT =A0GLOBAL HIDDEN =A0COM __cpu_= model >> =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. Right, I agree. But this problem exists right now even if libgcc_s.so is provided with these symbols. Please see example below: Example: dso.c ------- int some_func () { return (int) __builtin_cpu_is ("corei7"); } Build with gcc driver: $ gcc dso.c -fPIC -shared -o dso.so $ nm dso.so | grep __cpu 0000000000000780 t __cpu_indicator_init 0000000000001e00 b __cpu_model This DSO is getting its own local copy of __cpu_model. This is fine functionally but this is not the behaviour you have in mind. whereas, if I build with g++ driver: $ g++ dso.c -fPIC -shared dso.so $ nm dso.so | grep __cpu U __cpu_model This is as we would like, __cpu_model is undefined. The difference is that with the gcc driver, the link line is -lgcc -lgcc_s, whereas with the g++ driver -lgcc is not even present! Should I fix the gcc driver instead? This double-standard is not clear to m= e. Thanks, -Sri. > > -- > H.J.