From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12601 invoked by alias); 27 May 2012 02:23:33 -0000 Received: (qmail 12583 invoked by uid 22791); 27 May 2012 02:23:32 -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 02:23:17 +0000 Received: by obhx4 with SMTP id x4so3777274obh.20 for ; Sat, 26 May 2012 19:23:16 -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=yQwkmAhpW7vVucA34rPRIx0Non4fPPvTcXtyWHpUBzc=; b=oQLOBHHlcoG+4gHOHAwRGo1YkBNIZ4VtrIDyXgrjgBZHmUbgF0gXgrlukWl/I8aFfm Ws2iRmbwD11bxBCvpul+qSvAz4hxHLIytRPgKw8I0JcEGBxs3/tLdbIh2kvWodAamEpa s2qvtI1Wt9ArCqawgnKRSpFXgzeggdm8BMvruHH1xuZTTzALU8IyWSouLJfddSsu5jXp 99gRaUUXuZ4ZgxvX/P9WZSFf1EIIcYS0Hamq3KOYFqEBZWHciDc8VD14TVtgOq8i7XIj qJM87G7HHjyW91s2GURY06g5Gxv1PaJBsI200ZRbAM31q/IBGIS/ayIP1fkMv9rDYEDF 0sRw== Received: by 10.60.19.226 with SMTP id i2mr3792175oee.20.1338085396517; Sat, 26 May 2012 19:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.19.226 with SMTP id i2mr3792164oee.20.1338085396316; Sat, 26 May 2012 19:23:16 -0700 (PDT) Received: by 10.182.101.202 with HTTP; Sat, 26 May 2012 19:23:16 -0700 (PDT) In-Reply-To: References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> Date: Sun, 27 May 2012 02:23: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=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlCneA1gJvygScxD/BmZJ1fLrYY+gu0AK6Dq5IUXgslYGdUhPxOL6v/4plV9ceR+27ptt7FLUbgUSJxxNL+6Yz0+kdeUa2wE4kVTjdCDWB1WD6qjTozezTj8V+96W/qD7D3B899qPZC5tPUbyt23RarqWUYtw== 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/msg01817.txt.bz2 On Sat, May 26, 2012 at 7:06 PM, H.J. Lu wrote: > On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam wr= ote: >> On Sat, May 26, 2012 at 4:56 PM, H.J. Lu wrote: >>> On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam = wrote: >>>> 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" wr= ote: >>>>>>> > >>>>>>> > >>>>>>> > >> >>>>>>> > >> On Fri, May 25, 2012 at 5:0 > > BTW, I noticed: >>>>>>> >>>>>>> > > >>>>>>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep __cpu_model >>>>>>> > > =C2=A0 =C2=A020: 0000000000000010 =C2=A0 =C2=A016 OBJECT =C2=A0= GLOBAL HIDDEN =C2=A0 COM __cpu_model >>>>>>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so | grep __cpu_model >>>>>>> > > =C2=A0 =C2=A082: 0000000000214ff0 =C2=A0 =C2=A016 OBJECT =C2=A0= GLOBAL DEFAULT =C2=A0 24 >>>>>>> > > __cpu_model@@GCC_4.8.0 >>>>>>> > > =C2=A0 310: 0000000000214ff0 =C2=A0 =C2=A016 OBJECT =C2=A0GLOBA= L DEFAULT =C2=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_ >>>>> =C2=A0 =C2=A020: 0000000000000010 =C2=A0 =C2=A016 OBJECT =C2=A0GLOBAL= HIDDEN =C2=A0 COM __cpu_model >>>>> =C2=A0 =C2=A021: 0000000000000110 =C2=A0 612 FUNC =C2=A0 =C2=A0GLOBAL= HIDDEN =C2=A0 =C2=A0 4 __cpu_indicator_init >>>>> [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so.1 | grep _cpu_ >>>>> =C2=A0 =C2=A082: 0000000000214ff0 =C2=A0 =C2=A016 OBJECT =C2=A0GLOBAL= DEFAULT =C2=A0 24 >>>>> __cpu_model@@GCC_4.8.0 >>>>> =C2=A0 223: 0000000000002b60 =C2=A0 560 FUNC =C2=A0 =C2=A0LOCAL =C2= =A0DEFAULT =C2=A0 11 __cpu_indicator_init >>>>> =C2=A0 310: 0000000000214ff0 =C2=A0 =C2=A016 OBJECT =C2=A0GLOBAL DEFA= ULT =C2=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 =C2=A0__cpu_indicator_init exp= orted >>>>> 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 =C2=A0 =C2=A0DO .bss =C2=A0 0000000000000010 =C2=A0= GCC_4.8.0 =C2=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= /install/lib/gcc/x86_64-unknown-linux-gnu/libgcc.a >>>> | grep __cpu >>>> >>>> =C2=A0 20: 0000000000000010 =C2=A0 =C2=A016 OBJECT =C2=A0GLOBAL HIDDEN= =C2=A0COM __cpu_model >>>> =C2=A0 =C2=A021: 0000000000000110 =C2=A0 612 FUNC =C2=A0 =C2=A0GLOBAL = HIDDEN =C2=A0 =C2=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 () >> { >> =C2=A0 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 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 t= o me. >> > > =EF=BC=B4hat is because libgcc_s.so is preferred by g++. We can do one > of 3 things: > > 1. Abuse libgcc_eh.a by moving __cpu_model and __cpu_indicator_init > from libgcc.a to libgcc_eh.a. > 2. Rename libgcc_eh.a to libgcc_static.a and move __cpu_model and > __cpu_indicator_init from libgcc.a to libgcc_static.a. > 3. Add =C2=A0libgcc_static.a and move __cpu_model and __cpu_indicator_ini > =C2=A0from libgcc.a to libgcc_static.a. =C2=A0We treat libgcc_static.a si= milar to > libgcc_eh.a. Any reason why gcc should not be made to prefer libgcc_s.so too like g++? Thanks for clearing this up. I will take a stab at it. -Sri. > > > -- > H.J.