This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] powerpc64*: diverge sysdeps directories
On Wed, 06 Dec 2017, Joseph Myers wrote:
>On Wed, 6 Dec 2017, Gabriel F. T. Gomes wrote:
>> In preparation for the switch of the format of long double - from IBM
>> Extended Precision to IEEE 754 128-bits floating-point - on powerpc64le,
>> the sysdeps directories for powerpc64 and powerpc64le now diverge
>> further to allow them to imply different sets of subdirectories from
>> sysdeps. This patch moves sysdeps/powerpc/powerpc64 to
>> sysdeps/powerpc/powerpc64-common, then adjusts the inclusion of files in
>> C code, as well as it removes the Implies files which create the
>> hierarchy of processors.
>Could you give a more detailed indication of the design for how support
>for a third choice of long double for powerpc64le (in addition to the two
>existing choices currently present for powerpc64le) would be implemented
>so that it would build upon this change?
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
would also mean that many symbols for the float128 interface on
powerpc64le (for instance, __ieee754_acosf128) would disappear and that
the versioned symbols (for instance, acosf128) would point to the ldbl-128
implementation (for instance, to __ieee754_acosl).
On top of that, new, versioned, compat symbols would point to new
functions (for instance, __ibm128_ieee754_acosl). This would be
implemented on a new sysdeps directory (say ldbl-128ibm-compat), which
would reuse the files from ldbl-128ibm (changing their function names),
but would be included from new targets in the powerpc64le-specific
(For the record, I haven't implemented the compatibility code, yet. I
have only used the alias mechanism in a local branch (leading to a
temporary ABI breakage that I didn't plan to submit before the
compatibility code was ready)).
>There have been a few previous discussions touching on this question, with
>tentative observations that might suggest certain approaches as opposed to
>others (or that might be contradicted by more detailed design and
>implementation work), such as that:
>(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.
>(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.
>(c) there are a few legacy function not built for _Float128 that would
>need building in the case where it's an alternative long double format as
>they are non-compat symbols in the API for long double, but still without
>public *f128 interfaces (scalbl, nexttoward functions, etc.);
The functions not available for _Float128 would be provided by the alias
mechanism for the new long double format, whereas the compat version
would be built from ldbl-128ibm-compat/ldbl-128ibm and provided as new
symbols (as pointed out above, I had assumed it would be OK).
>(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.
>(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
OK. This is something else I need more time to think of.
>But not I think any detailed design discussions or branches to flesh out
I did not understand this sentence.
>The following is not directly related to this patch: we *already* have
>separate sysdeps directories for powerpc64le (and this patch would create
>more). Given that we have such directories, is there any need any more
>for the mechanism of having *-le.abilist files? Or should that mechanism
>be removed, to simplify the architecture-independent code related to ABI
>tests and reduce confusion about one set of baselines not being called
>libc.abilist etc., and the powerpc64le ABI baselines be moved to
>sysdeps/unix/sysv/linux/powerpc/powerpc64le without the -le in their
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
agree it would be more clear to move/rename these files and get rid of the
>> Future commits will move files related to the long double implementation
>> of IBM Extended Precision from sysdeps/powerpc/powerpc64-common to
>Unless you intend a clean ABI break with new symbol versions for
>everything (in which case all of (a) through (e) are irrelevant), I'd
>expect all the IBM long double files still to be relevant to powerpc64le
>as they'd still need to implement the same symbols at the same symbol
>versions as at present.
I don't intend to break the ABI. However, since I was planning to use the
alias mechanism, I wanted to *imply* ldbl-128 *instead* of ldbl-128ibm.
Then, for the IBM long double implementation, I was indeed planning to use
the files under ldbl-128ibm, but only through includes from a new
directory (ldbl-128ibm-compat), not via the Implies mechanism.