From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18686 invoked by alias); 29 Jun 2018 14:12:50 -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 18385 invoked by uid 89); 29 Jun 2018 14:12:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=mar, HTo:D*br, Mar, sk:LONG_DO X-HELO: mx1.redhat.com Subject: Re: [PATCH 2/9] Add __vfscanf_internal and __vfwscanf_internal with flags arguments. To: "Gabriel F. T. Gomes" , Zack Weinberg Cc: libc-alpha@sourceware.org References: <20180307193205.4751-1-zackw@panix.com> <20180307193205.4751-3-zackw@panix.com> <20180326122752.64b6591b@tereshkova> From: Florian Weimer Message-ID: Date: Fri, 29 Jun 2018 14:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180326122752.64b6591b@tereshkova> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00980.txt.bz2 On 03/26/2018 05:27 PM, Gabriel F. T. Gomes wrote: > On Wed, 07 Mar 2018, Zack Weinberg wrote: > >> (It was necessary to introduce ldbl_compat_symbol for _IO_vfscanf. >> Please check that part of the patch very carefully, I am still not >> confident I understand all of the details of ldbl-opt.) > > It looks good on powerpc64... Oldest symbol (where long double had the > same format as double) is still there as a compat symbol with version > GLIBC_2.3... The newer symbol, is a bit different, in the sense that it > is now a compat symbol (it was a default symbol previously). > > Here's what readelf has to tell us: > > Before the patch set: > 1355: 00000000001eea70 124 FUNC GLOBAL DEFAULT 27 _IO_vfscanf@GLIBC_2.3 > 1356: 00000000001f0a98 23552 FUNC GLOBAL DEFAULT 27 _IO_vfscanf@@GLIBC_2.4 > > After the patch set: > 1355: 00000000001f0bd0 136 FUNC GLOBAL DEFAULT 27 _IO_vfscanf@GLIBC_2.4 > 1356: 00000000001ee968 136 FUNC GLOBAL DEFAULT 27 _IO_vfscanf@GLIBC_2.3 I think that's correct and intended because there is no user redirect to _IO_vfscanf in public headers, and libndbl_nonshared.a does not use this interface, either (it uses __nldbl__IO_vfscanf). >> --- a/sysdeps/ieee754/ldbl-opt/math_ldbl_opt.h >> +++ b/sysdeps/ieee754/ldbl-opt/math_ldbl_opt.h >> @@ -20,10 +20,14 @@ >> long_double_symbol (libc, __GL_##name##_##aliasname, aliasname); >> # define long_double_symbol_1(lib, local, symbol, version) \ >> versioned_symbol (lib, local, symbol, version) >> +# define ldbl_compat_symbol(lib, local, symbol, version) \ >> + compat_symbol (lib, local, symbol, LONG_DOUBLE_COMPAT_VERSION) >> #else >> # define ldbl_hidden_def(local, name) libc_hidden_def (name) >> # define ldbl_strong_alias(name, aliasname) strong_alias (name, aliasname) >> # define ldbl_weak_alias(name, aliasname) weak_alias (name, aliasname) >> +# define ldbl_compat_symbol(lib, local, symbol, version) \ >> + compat_symbol (lib, local, symbol, version) > > I believe that Adhemerval's comment is correct and ldbl_compat_symbol > should translate to nothing when building static libraries. The shared library should not contain any definition for the compat symbol. The SHLIB_COMPAT mechanism takes care of that. But I do wonder if we need this mechanism at all. Wouldn't it be more appropriate to define LONG_DOUBLE_COMPAT_VERSION by default, as GLIBC_2_0, and then just use compat_symbol (libc, __IO_vfscanf, _IO_vfscanf, LONG_DOUBLE_COMPAT_VERSION); ? This pretends that GLIBC_2_0 already underwent the long double transition, and this seems somewhat consistent to me. Thanks, Florian