* 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).