Re: [PATCH] powerpc64*: diverge sysdeps directories

[Joseph Myers <joseph at codesourcery dot com>]

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?

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;

(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;

(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.);

(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;

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

But not I think any detailed design discussions or branches to flesh out 
the design.

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?

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

-- 
Joseph S. Myers
joseph@codesourcery.com