* Legacy _IO_* symbols and Flaot128 transition @ 2018-06-29 14:49 Florian Weimer 2018-06-29 15:26 ` Gabriel F. T. Gomes 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2018-06-29 14:49 UTC (permalink / raw) To: GNU C Library, Gabriel F. T. Gomes libio exports a bunch of symbols for historic reasons: _IO_fprintf _IO_printf _IO_sprintf _IO_sscanf _IO_vfprintf _IO_vfscanf _IO_vsprintf These aren't compat symbols yet, but will not be in installed headers for glibc 2.28. Zack's cleanup patches only turns _IO_vfscanf into a compat symbol (in âAdd __vfscanf_internal and __vfwscanf_internal with flags arguments.â). I think we should turn all of them into compat symbols and drop their compatibility wrappers from nldbl_nonshared.a, and avoid adding binary128 compatibility wrappers for them. I can work on a patch if that would help. Comments? Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Legacy _IO_* symbols and Flaot128 transition 2018-06-29 14:49 Legacy _IO_* symbols and Flaot128 transition Florian Weimer @ 2018-06-29 15:26 ` Gabriel F. T. Gomes 2018-06-29 15:29 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Gabriel F. T. Gomes @ 2018-06-29 15:26 UTC (permalink / raw) To: Florian Weimer; +Cc: GNU C Library On Fri, 29 Jun 2018, Florian Weimer wrote: >libio exports a bunch of symbols for historic reasons: > >_IO_fprintf >_IO_printf >_IO_sprintf >_IO_sscanf >_IO_vfprintf >_IO_vfscanf >_IO_vsprintf > >These aren't compat symbols yet, but will not be in installed headers >for glibc 2.28. Zack's cleanup patches only turns _IO_vfscanf into a >compat symbol (in “Add __vfscanf_internal and __vfwscanf_internal with >flags arguments.”). > >I think we should turn all of them into compat symbols and drop their >compatibility wrappers from nldbl_nonshared.a, and avoid adding >binary128 compatibility wrappers for them. Should they be turned into compat symbols *because* they won't be installed headers (and we don't want new user code linking against them)? Or is there something else to it? As for binary128 compatibility wrappers for them, I agree (I haven't created these on my branch, so this should already be in sync with your suggestions). >I can work on a patch if that would help. That would help a lot! :) Thanks, Gabriel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Legacy _IO_* symbols and Flaot128 transition 2018-06-29 15:26 ` Gabriel F. T. Gomes @ 2018-06-29 15:29 ` Florian Weimer 2018-06-29 17:15 ` Joseph Myers 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2018-06-29 15:29 UTC (permalink / raw) To: Gabriel F. T. Gomes; +Cc: GNU C Library On 06/29/2018 05:26 PM, Gabriel F. T. Gomes wrote: > On Fri, 29 Jun 2018, Florian Weimer wrote: > >> libio exports a bunch of symbols for historic reasons: >> >> _IO_fprintf >> _IO_printf >> _IO_sprintf >> _IO_sscanf >> _IO_vfprintf >> _IO_vfscanf >> _IO_vsprintf >> >> These aren't compat symbols yet, but will not be in installed headers >> for glibc 2.28. Zack's cleanup patches only turns _IO_vfscanf into a >> compat symbol (in âAdd __vfscanf_internal and __vfwscanf_internal with >> flags arguments.â). >> >> I think we should turn all of them into compat symbols and drop their >> compatibility wrappers from nldbl_nonshared.a, and avoid adding >> binary128 compatibility wrappers for them. > > Should they be turned into compat symbols *because* they won't be > installed headers (and we don't want new user code linking against them)? > Or is there something else to it? No, it's just a cleanup, and to clarify what's necessary for future work. I also want to add some minimal test for libnldbl_nonshared.a, and reducing its size helps with that. (I'm aware that on ppc64, the current toolchain doesn't support long double as double anymore, but I can just lie to the compiler and use double instead, I guess.) > As for binary128 compatibility wrappers for them, I agree (I haven't > created these on my branch, so this should already be in sync with your > suggestions). Good to know. Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Legacy _IO_* symbols and Flaot128 transition 2018-06-29 15:29 ` Florian Weimer @ 2018-06-29 17:15 ` Joseph Myers 2018-07-02 7:22 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Joseph Myers @ 2018-06-29 17:15 UTC (permalink / raw) To: Florian Weimer; +Cc: Gabriel F. T. Gomes, GNU C Library On Fri, 29 Jun 2018, Florian Weimer wrote: > > Should they be turned into compat symbols *because* they won't be > > installed headers (and we don't want new user code linking against them)? > > Or is there something else to it? > > No, it's just a cleanup, and to clarify what's necessary for future work. Anything not accessible from installed headers is a good candidate for making into a compat symbol. > I also want to add some minimal test for libnldbl_nonshared.a, and reducing > its size helps with that. (I'm aware that on ppc64, the current toolchain > doesn't support long double as double anymore, but I can just lie to the > compiler and use double instead, I guess.) It certainly appears to be supported to me (using GCC mainline, compiling with -mlong-double-64 produces sizeof (long double) == 8 for both powerpc64 and powerpc64le). However, libnldbl_nonshared.a is for long double = double *with compilers not supporting asm redirection*. Which is a case the (incorrect) patch in <https://sourceware.org/ml/libc-alpha/2014-08/msg00497.html> provides evidence hasn't worked for a long time. So I still think there's a case for eliminating libnldbl_nonshared.a and explicitly requiring asm redirection support for these non-default long double variants, which it's in practice required already (if not more generally requiring it for any compiler using the glibc headers), as discussed in <https://sourceware.org/ml/libc-alpha/2018-03/msg00281.html>. (The actual __nldbl_* exports from the glibc shared libraries - the functions that get used with -mlong-double-64 given asm redirection support - *should* be tested, via building some tests with -mlong-double-64. The binary128 work should, as per <https://sourceware.org/ml/libc-alpha/2018-06/msg00680.html>, add tests that are generic to different long double formats, so that it will then be easy to build them for -mlong-double-64 for ldbl-opt configurations.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Legacy _IO_* symbols and Flaot128 transition 2018-06-29 17:15 ` Joseph Myers @ 2018-07-02 7:22 ` Florian Weimer 0 siblings, 0 replies; 5+ messages in thread From: Florian Weimer @ 2018-07-02 7:22 UTC (permalink / raw) To: Joseph Myers; +Cc: Gabriel F. T. Gomes, GNU C Library On 06/29/2018 07:15 PM, Joseph Myers wrote: > On Fri, 29 Jun 2018, Florian Weimer wrote: > >>> Should they be turned into compat symbols *because* they won't be >>> installed headers (and we don't want new user code linking against them)? >>> Or is there something else to it? >> >> No, it's just a cleanup, and to clarify what's necessary for future work. > > Anything not accessible from installed headers is a good candidate for > making into a compat symbol. Agreed. >> I also want to add some minimal test for libnldbl_nonshared.a, and reducing >> its size helps with that. (I'm aware that on ppc64, the current toolchain >> doesn't support long double as double anymore, but I can just lie to the >> compiler and use double instead, I guess.) > > It certainly appears to be supported to me (using GCC mainline, compiling > with -mlong-double-64 produces sizeof (long double) == 8 for both > powerpc64 and powerpc64le). Oh, this option isn't documented for POWER, so I didn't try it. > However, libnldbl_nonshared.a is for long double = double *with compilers > not supporting asm redirection*. Which is a case the (incorrect) patch in > <https://sourceware.org/ml/libc-alpha/2014-08/msg00497.html> provides > evidence hasn't worked for a long time. So I still think there's a case > for eliminating libnldbl_nonshared.a and explicitly requiring asm > redirection support for these non-default long double variants, which it's > in practice required already (if not more generally requiring it for any > compiler using the glibc headers), as discussed in > <https://sourceware.org/ml/libc-alpha/2018-03/msg00281.html>. Okay, I review the situation to determine which way is the best way forward for the 2.28 release. > (The actual __nldbl_* exports from the glibc shared libraries - the > functions that get used with -mlong-double-64 given asm redirection > support - *should* be tested, via building some tests with > -mlong-double-64. The binary128 work should, as per > <https://sourceware.org/ml/libc-alpha/2018-06/msg00680.html>, add tests > that are generic to different long double formats, so that it will then be > easy to build them for -mlong-double-64 for ldbl-opt configurations.) I suppose we should also add tests for the functions which are not redirected to __nldbl_* variants, but to the non-l variants (because only for things like printf, separate wrappers are needed if there is redirection support). Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-02 7:22 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-29 14:49 Legacy _IO_* symbols and Flaot128 transition Florian Weimer 2018-06-29 15:26 ` Gabriel F. T. Gomes 2018-06-29 15:29 ` Florian Weimer 2018-06-29 17:15 ` Joseph Myers 2018-07-02 7:22 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).