From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22129 invoked by alias); 11 Aug 2017 18:53:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 22056 invoked by uid 89); 11 Aug 2017 18:53:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=frowned X-HELO: homiemail-a83.g.dreamhost.com Subject: Re: [PATCH 0/2] Multiarch hooks for memcpy variants To: Zack Weinberg , Szabolcs Nagy Cc: Wilco Dijkstra , "libc-alpha@sourceware.org" , nd References: <18d2fdf8-ca55-1ded-fa66-3509b3bcf8fe@gotplt.org> <598DF02B.8010607@arm.com> From: Siddhesh Poyarekar Message-ID: <4072a19f-eecb-8cdd-889f-46b4c8b968b4@gotplt.org> Date: Fri, 11 Aug 2017 18:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg00468.txt.bz2 On Friday 11 August 2017 11:36 PM, Zack Weinberg wrote: >> may be the generic __memcpy_chk should call the ifunced >> memcpy so it goes through an extra plt indirection, but >> at least less target specific code is needed. > > I was thinking of making this suggestion myself. I think that would > be a better maintainability/efficiency tradeoff. (Of course, I also > think we shouldn't bypass ifuncs for intra-libc calls.) That was my initial approach, but I was under the impression that PLTs in internal calls were frowned upon, hence the ifuncs similar to what's done in x86. If this is acceptable, I could do more tests to check gains within the library if we were to call memcpy via ifunc. Siddhesh