From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by sourceware.org (Postfix) with ESMTPS id 257C7385780D for ; Fri, 19 Mar 2021 19:02:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 257C7385780D Received: by mail-qk1-x72f.google.com with SMTP id g15so4050731qkl.4 for ; Fri, 19 Mar 2021 12:02:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lZhDsYA/+i8fk77MsMmRol2hb5i3D9jZTjKpLtFvtSQ=; b=gq1tUwJMSC7z7aOByNjnef7Bt4cU7oy7NdzWp/7H4na/T54XDCvXAleBRVcKWhnX8U LEO4/RI14HG5TTChGOjrw/jEz1pNYmDlyensXU7Hur9H3+rYOFr5uqTlo1cruqGAdNfj Iv2Jcfh+0YuVlulrVZP0GRRx3OBNrBQ6wgN7lDHolGRiHRpojkbzMBZ7ddrPzIqQtlcL M13+UVQ3MPMW7uiE8TaBk1n4zpyVp3vX+iUw771LiM6G4Qi14bZ9vsaIGzSIg/yeDvew Orxu6eMYLp2+DGgnJv42tBzSemOe0shEo6KgOOOww7GkW2ijyb+geJL533e7vmWis9kz y94g== X-Gm-Message-State: AOAM530ltAbDUhVQMaEeNwbNuu8c3nXZJTqPAFG7pCOLkYz85QGcegXQ sjVzgMCJXSH6ZIsiTvhabvU1EgxFnqL8bb1a X-Google-Smtp-Source: ABdhPJz2ua2lthapMhgXMazFd2mmedmwjwvbjnG5qwNRTWPSiMuZ92UMQoKUJsotm0YK6/hR+h9MBw== X-Received: by 2002:a37:65d4:: with SMTP id z203mr77292qkb.254.1616180557782; Fri, 19 Mar 2021 12:02:37 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id l129sm5217754qkd.76.2021.03.19.12.02.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Mar 2021 12:02:37 -0700 (PDT) Subject: Re: [RFC 0/2] Transparent multi-version symbol support To: libc-alpha@sourceware.org, Florian Weimer References: From: Adhemerval Zanella Message-ID: Date: Fri, 19 Mar 2021 16:02:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 19:02:39 -0000 On 18/03/2021 17:06, Florian Weimer via Libc-alpha wrote: > This turned out to be way harder than it should be. Older binutils does > not support multiple .symver directives for the same first symbol, so we > have various kludges like (from time/clock_settime.c): > > | versioned_symbol (libc, __clock_settime, clock_settime, GLIBC_2_17); > | > | /* clock_settime moved to libc in version 2.17; > | old binaries may expect the symbol version it had in librt. */ > | #if SHLIB_COMPAT (libc, GLIBC_2_2, GLIBC_2_17) > | strong_alias (__clock_settime, __clock_settime_2); > | compat_symbol (libc, __clock_settime_2, clock_settime, GLIBC_2_2); > | #endif > > I think I have found a way to do this with assembler hacks, so that it > applies to function and data symbols alike. With this, the above > snipper becomes: > > | versioned_symbol (libc, __clock_settime, clock_settime, GLIBC_2_17); > | > | /* clock_settime moved to libc in version 2.17; > | old binaries may expect the symbol version it had in librt. */ > | #if SHLIB_COMPAT (libc, GLIBC_2_2, GLIBC_2_17) > | compat_symbol (libc, __clock_settime, clock_settime, GLIBC_2_2); > | #endif > > So the explicit aliases are gone. > > Built with build-many-glibcs.py with binutils 2.36 and 2.34. Tested on > i686-linux-gnu and x86_64-linux-gnu with binutils 2.34 and 2.35. > > The object files aren't unchanged due to the __malloc_initialize_hook > change (and presumably others, I haven't looked closely). Thanks for working on this, I have checked on the all architectures that generated abilist and I saw not regression on a make check (with run-built-tests=no). The only detail I am not sure is if SYMVER_NEEDS_ALIAS does yields any substantial gain (and it require some refactoring and code to handle it). What kind of improvement do you expect?