This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/9] Add __vfscanf_internal and __vfwscanf_internal with flags arguments.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]