This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc64*: diverge sysdeps directories
On Wed, 6 Dec 2017, Gabriel F. T. Gomes wrote:
> An overview would be that I was planning to build upon the aliasing
> mechanism that you wrote for mips, s390x, etc. This means that I was
> planning for powerpc64le to imply ldbl-128, rather than ldbl-128ibm. This
That could probably work, but it seems likely to be more complicated than
keeping building with -mabi=ibmlongdouble (so keeping the same sysdeps
implications, but with additional aliases for float128 functions to be
namespace-clean, and appropriate header magic - header magic being needed
in any case).
(Cf. how it would be nice for ldbl-128 functions to build with the *f128
names unconditionally and *l aliases conditionally, with most of the
macros from float128_private.h then being eliminated. But right now we
have float128_private.h, which works and was certainly a much simpler
point to get to. Or cf. how a patch proposed a while back to make
_FILE_OFFSET_BITS=64 the default still kept glibc itself building with
_FILE_OFFSET_BITS=32 to avoid many problems arising.)
> >(a) it might be undesirable to have any new APIs that are explicitly for
> >use of IBM long double in a context where long double is binary128;
>
> My intention with the approach I described above was that the old
> implementations would be accessible through external symbol versioning
> (for instance, acosl@GLIBC_2.17) to new symbols (for instance,
> __ibm128_ieee754_acosl). I was assuming, perhaps incorrectly, that adding
> such new symbols would be OK.
(i) New internal, non-exported symbols should certainly be OK.
(ii) It's new APIs - allowing the user to call acosibm128, for example,
with declarations of such names in the public headers - that I think
should be avoided. Rather, people wishing to use IBM long double
functions after a change of default should compile their programs with
-mabi=ibmlongdouble.
(iii) Regarding new internal-namespace ABIs, some may be needed (or else a
compiler extension to allow the headers to specify a symbol version to use
with a function, but new internal-namespace ABIs would be less
disruptive). Adding a single set of new ABIs to be used when float128
functions are called as long double (e.g. __acosf128, symbol version
GLIBC_2.28) is a smaller addition than adding a new set of ABIs for
float128 functions called as long double (e.g. acosl, symbol version
GLIBC_2.28) *and* a new set of ABIs for ibm128 functions so they can still
be accessed with -mabi=ibmlongdouble (e.g. __ibm128_acosl, version
GLIBC_2.28). Though the latter is effectively the approach followed with
__nldbl_*.
The precise set of ABIs should more or less just be a matter of how you
set up the libm_alias_* macros and associated Versions entries and header
magic. Note that I didn't convert any IBM long double files (whether in
ldbl-128ibm or in powerpc sysdeps directories) to using
libm_alias_ldouble, simply because it wasn't relevant for my _Float* work.
Whatever you do, being able to have test coverage for both long double
modes would be a very good idea. Right now, there is *no* test coverage
for -mlong-double-64 at all, on any platform that supports it.
(iv) For functions already exported under internal-namespace ABIs, there
should be no need to add any more such ABIs. __isinfl and __isinff128
fully suffice to provide isinf functionality for both types, all that's
needed is to ensure they are declared with appropriate types in the case
where long double is binary128 (so __isinfl would have __ibm128 argument
then) and that the type-generic macros result in that case in *f128 being
used for long double and *l being used for __ibm128. Likewise for the
__*_finite ABIs.
(You could argue there's no need for the type-generic macros to support
__ibm128 when long double is binary128. In that case, you just need to
make sure __isinff128 not __isinfl gets called for long double arguments.)
> >(b) strict namespace conformance would mean mapping *l calls (when long
> >double is binary128) to new __*f128 exports but without strict conformance
> >they could map to *f128;
>
> I thought of it the other way around, i.e. new __ibm128_*l symbols.
Well, if you provide new symbol versions of acosl and all the other such
functions then it can be done that way.
> >(d) the approach used in the present ldbl-opt support for different long
> >double formats in printf-like functions - setting a TLS variable to
> >indicate the long double format in a compat wrapper before calling the
> >main function - would be questionable for any new uses because of
> >AS-safety considerations and a desire for dprintf at least to be AS-safe
> >in some cases;
>
> I wasn't aware of that being questionable. I'll need more time to
> understand how to avoid this.
Arguably, internal functions taking an explicit parameter for the kind of
long double in use (though preferably you want to arrange things so the
parameter doesn't exist for configurations that don't need it).
(The present code doesn't even save and restore the TLS variable, just
sets it to 1 then to 0, so would also run into problems if a function
compiled with one long double choice were called from within a printf-like
function compiled with a different long double choice, e.g. through the
use of printf hooks.)
> >(e) the set of printf-like functions with ldbl-opt compatibility is
> >incomplete (missing at least argp.h, err.h, error.h functions) and such
> >incompleteness should not be replicated when adding a third choice of long
> >double.
>
> OK. This is something else I need more time to think of.
It's probably one of the more straightforward pieces. Review the
installed headers to find all printf/scanf/strfmon-like functions and get
a complete list of those without long double compatibility, and add
compatibility for those that lack it. Then, __LDBL_REDIR_DECL etc. macros
can be used for all functions with such compatibility (and whatever
approach you use for a third long double choice, those macros will need a
powerpc version that handles having the three variants).
You can't solve the ambiguity for pre-2.4 symbol versions of such
functions lacking compatibility, which might have been called by pre-2.4
problems expecting long double = double or by post-2.4 programs expecting
long double = IBM long double. But you can add __nldbl_* variants so
future programs built with -mlong-double=64 work correctly with these
functions, and by adding the __LDBL_REDIR_DECL etc. calls you put the
machinery in place for these functions to work properly when there is a
third long double variant as well.
> >But not I think any detailed design discussions or branches to flesh out
> >the design.
>
> I did not understand this sentence.
It's following on from the previous sentence that started before (a) -
"There have been a few previous discussions touching on this question ....
But not I think any detailed design discussions ....".
> Thanks for pointing that out. I also bumped into these files while
> working on the subdirectory renaming, but I wasn't aware that the
> mechanism of having *-le.abilist was there only because of powerpc64le. I
It was because initially powerpc64le had different symbol versions but not
any other need for different sysdeps directories.
--
Joseph S. Myers
joseph@codesourcery.com