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] 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
Makefile.

(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 
>double.

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 
>the design.

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 
>names?

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
mechanism.

>> Future commits will move files related to the long double implementation
>> of IBM Extended Precision from sysdeps/powerpc/powerpc64-common to
>> sysdeps/powerpc/powerpc64.  
>
>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.


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