From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62505 invoked by alias); 11 May 2015 14:12:25 -0000 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 Received: (qmail 62494 invoked by uid 89); 11 May 2015 14:12:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 May 2015 14:12:23 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1YroQM-000281-00; Mon, 11 May 2015 14:11:14 +0000 Date: Mon, 11 May 2015 14:12:00 -0000 From: Rich Felker To: Jakub Jelinek Cc: Szabolcs Nagy , Szabolcs Nagy , "H.J. Lu" , Uros Bizjak , Mike Stump , Jack Howarth , Ian Lance Taylor , GCC Patches , Iain Sandoe , Rainer Orth Subject: Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE Message-ID: <20150511141114.GR17573@brightrain.aerifal.cx> References: <20150417113731.GL1725@tucnak.redhat.com> <20150417115950.GM1725@tucnak.redhat.com> <20150509143104.GA26462@port70.net> <20150509185737.GA31118@port70.net> <5550825F.1050300@arm.com> <20150511103151.GW1751@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150511103151.GW1751@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg00938.txt.bz2 On Mon, May 11, 2015 at 12:31:51PM +0200, Jakub Jelinek wrote: > On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote: > > > > > > On 09/05/15 19:57, Szabolcs Nagy wrote: > > > * H.J. Lu [2015-05-09 10:41:41 -0700]: > > >> There are > > >> > > >> 4: 0000000000002b70 806 FUNC GLOBAL DEFAULT 12 > > >> __cpu_indicator_init@GCC_4.8.0 > > >> 38: 00000000002153d0 16 OBJECT GLOBAL DEFAULT 25 __cpu_model@GCC_4.8.0 > > >> > > >> and > > >> > > >> 000000000215000 0000000400000001 R_X86_64_64 > > >> 0000000000002b70 __cpu_indicator_init@GCC_4.8.0 + 0 > > >> 0000000000215220 0000002600000006 R_X86_64_GLOB_DAT > > >> 00000000002153d0 __cpu_model@GCC_4.8.0 + 0 > > >> > > >> in libgcc_s.so.1. Musl ld.so must be fixed to handle it. > > >> > > > > Rich is looking at how to do this non-intrusively, but > > it seems non-trivial (some users of musl prefer not to > > resolve such versioned symbols). > > > > > > > > i think it might be enough to add __cpu_indicator_init_local > > > as an alias to __cpu_indicator_init in libgcc.a and then use > > > the *_local symbol from the ifunc resolver, that way no new > > > dependency is added to libgcc_s.so handling. > > > > i tried this approach and it seems to work: passes all > > multiversioning tests on x86_64. > > > > i think it's no worse than the symver approach. > > > > is it ok to change the current fix to this? > > No. Instead of piling hacks like this just fix it in musl. I wouldn't call it piling hacks; it's an improvement as far as I can tell since it remove symbolic relocations and replaces them with relative ones. > libgcc certainly isn't the only library that uses @ symbol versions, > e.g. libstdc++ does as well, as well as many other shared libraries. We haven't encountered such issues there. Rich