From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28216 invoked by alias); 26 May 2012 22:35:08 -0000 Received: (qmail 28014 invoked by uid 22791); 26 May 2012 22:35:05 -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,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; Sat, 26 May 2012 22:34:52 +0000 Received: by obhx4 with SMTP id x4so3554493obh.20 for ; Sat, 26 May 2012 15:34:51 -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=MJyK/q8N1qo3IciDOA8DkT/mdwoL3lv7i4alh5WcJE0=; b=aYCFHJ3+uAKb1+eiP6co+Uo2iPiNZl61ndXqFRTPy7L/nue9ilpwZUvDts7OpC6IGe LZ8moUpTplga6kcbDpiP8I3IgiHRF8S7HTuHUhGZEpAQ30zs0dJXwNAoDv8NQagHrDbu pgmVqMybYTyhvW77EYN3+2k5N6Voxt1g+fzCUUhd2RJKJvCVqo1rJDUmwzX510r9ygih z1V0EEwly3XhIMGL81nuZ8QyWiI5rLY/M9QaHbAfGY/dHfjoFJ3vRQKFYnuE/RQwWvpp 4IV7cR/JIksRWqMPj3wNh6WUfsLXofBA9rZ0KTMZ9kHX1NekBaKdHHwCwY2lVFeB26PH EQzw== Received: by 10.182.2.193 with SMTP id 1mr3406511obw.46.1338071691687; Sat, 26 May 2012 15:34:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.193 with SMTP id 1mr3406498obw.46.1338071691513; Sat, 26 May 2012 15:34:51 -0700 (PDT) Received: by 10.182.101.202 with HTTP; Sat, 26 May 2012 15:34:51 -0700 (PDT) In-Reply-To: References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> Date: Sat, 26 May 2012 22:35: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: ALoCoQnhUzfrsjCFwAjNyDm+v866vNLOKZNs0N1wOSOUJXfcEgvj+EtSAQSklIgA2L77q70zNuihNHoQKs5Bmay5zhTmBuLxqW+9WCvFpxhVKpkyYfloscqSx2qYoWz1RsYN+nDJlOocU1SCoonylbkee5oHbjLEUg== 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/msg01809.txt.bz2 On Fri, May 25, 2012 at 10:05 PM, H.J. Lu wrote: > On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam wr= ote: >> >> 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 C= OM __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 __c= pu_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 __c= pu_indicator_init > =A0 310: 0000000000214ff0 =A0 =A016 OBJECT =A0GLOBAL DEFAULT =A0 24 __cpu= _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 DO .bss 0000000000000010 GCC_4.8.0 __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. 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? In libgcc.a: readelf -sWt /g/tmsriram/GCC_trunk_svn_mv_fe_at_nfs/native_builds/bld1/inst= all/lib/gcc/x86_64-unknown-linux-gnu/libgcc.a | grep __cpu 20: 0000000000000010 16 OBJECT GLOBAL HIDDEN COM __cpu_model 21: 0000000000000110 612 FUNC GLOBAL HIDDEN 4 __cpu_indicator_i= nit 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? Example: file:test.c int main () { return (int) __builtin_cpu_is ("corei7"); } Case I : Use gcc to build dynamic $ gcc test.c -Wl,-y,__cpu_model libgcc.a(cpuinfo.o): reference to __cpu_model libgcc_s.so: definition of __cpu_model Case II: Use g++ to build dynamic $ g++ test.c -Wl,-y,__cpu_model fe1.o: reference to __cpu_model libgcc_s.so: definition of __cpu_model Case III: Use gcc to link static $ gcc test.c -Wl,-y,__cpu_model -static fe1.o: reference to __cpu_model libgcc.a(cpuinfo.o): reference to __cpu_model Please note that in all 3 cases, libgcc.a was linked in. Hence, removing these symbols from the dynamic symbol table of libgcc_s.so should have no issues. Thanks, -Sri. > > -- > H.J.