From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2F6E31F405 for ; Tue, 18 Dec 2018 13:03:45 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:date :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id; q=dns; s=default; b=pCjCC4ndbwdSxKksjxlJw0HMSDM7fT9 37OeMqKauLz5yfhgyqL04PuxIrYYc5xAEuc2aoeMRliUT4JyCBG9KE5k6ADbJJik eeV3XJhXqj8f3KCphdDELSdLG2WXx0Zeq+vhwh5Vz4DGayCx4v5FvhtaETR6NhRN fO4FwNaIzob0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:date :mime-version:in-reply-to:content-type:content-transfer-encoding :message-id; s=default; bh=rUfrT0Z16IsHMVxikKU/HRdl7ws=; b=OhUEU Ke02JgId+tErZO4SItq6SXZfOUnYpJWtjWkeulVbR1tRO61+hXak60cF4V3BiyQN ao/M6P/p4beZ3WEBotxwLjKuGnE0dhIR56bpcakqA3jriPsQjQeC4rOikzJOJkJs HaQHayx2jQk1L+RfJNICnJBSL1w0ONWjQsUBTY= Received: (qmail 47589 invoked by alias); 18 Dec 2018 13:03:42 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 47578 invoked by uid 89); 18 Dec 2018 13:03:41 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH] S390: Refactor ifunc handling To: libc-alpha@sourceware.org References: <1543593514-10251-1-git-send-email-stli@linux.ibm.com> <6790286e-1106-29d4-26ee-51342ac693e5@linaro.org> <630b68da-146b-fb0a-3119-4923614107ad@linux.ibm.com> <9d44a47f-0f15-720a-c779-80ce2ca431c6@linaro.org> <14c427d8-6129-8239-f87f-a22bf6f54bc9@linaro.org> <8eaa5fa3-503e-f366-356f-f22ddb4bd78a@linux.ibm.com> <18bbc489-cb2f-0493-54fc-5e6c86496d0c@linux.ibm.com> Cc: Andreas Krebbel From: Stefan Liebler Date: Tue, 18 Dec 2018 14:03:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <18bbc489-cb2f-0493-54fc-5e6c86496d0c@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit x-cbid: 18121813-0020-0000-0000-000002F9485E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18121813-0021-0000-0000-000021494B99 Message-Id: <71a0371f-994f-8fb2-04de-2ff8fea287b9@linux.ibm.com> On 12/11/2018 03:46 PM, Stefan Liebler wrote: > Hi all, > > after all the comments, we've also re-discussed the approach internally. > We still see more advantages (apart from performance-perspective) than > disadvantages and thus plan to commit the patches if there are no strong > objections. > > I've summarized some points: > -Reducing code size as not used ifunc variants are omitted. E.g. when > building with march >= zEC12 we have only one variant for memset, > memcmp, memcpy instead of three for each. When building with march >= > z13 we have only the vector variants for the string functions. > > -Ifunc symbols are avoided at all (if we have only one remaining ifunc > variant). In the most tools like binutils, gdb and co, ifunc symbols are > implemented as separate more complex code paths. Thus we think it is > better to have less ifuncs. E.g. setting a breakpoint on an ifunc'ed > symbol is more complicated than for an usual symbol. > > -Automatically using the best available ifunc variant as glibc internal > symbol (depending on the used gcc-options) without adding the > plut-stub-overhead. The same applies to --disable-multiarch and ld.so. > > -Introducing ifunc'ed glibc internal symbol is not possible on s390-32 > as a non plt-relocation is generated by gcc but an implicit plt-stub is > used. The plt-stub needs the GOT-pointer in r12 which was not loaded by > gcc. > > -Calling a non-ifunc'ed glibc internal symbols is just a brasl to this > symbol. There are no special hacks. What shall go wrong? Whereas calling > an ifunc'ed glibc internal symbol involves the additional special plt-stub. > > -As the code is shared between s390-32 and s390-64 we do not want to > introduce ifunc'ed glibc internal symbols for e.g. s390-64 and > non-ifunc'ed ones for s390-32. > > -Testing glibc needs to be done for all march-levels - with or without > these patches. Thus we don't see the more testing effort. > > -Testing the implementation of all different ifunc variants of a > specific function is still possible with ifunc-impl-list mechanism if > march-level is set to the oldest march-level. > > Bye > Stefan > Committed.