powerpc-nofpu ABI baselines

powerpc-nofpu ABI baselines

[Joseph S. Myers]

I've added ABI baselines for powerpc-nofpu in 
sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/nptl/.  Rather than 
sending the large files here, instead here's the diff against the 
baselines for powerpc32-fpu.  I think the changes here are correct - that 
is, the symbols really were in the relevant versions (although I only did 
some spot checks against 2.5 binaries, not 2.3/2.4), and at least as of 
2.5 it really does seem to be the case that powerpc-nofpu glibc does not 
export the __longjmp symbol at all, so the removal of that symbol 
(relative to the fpu version) seems right.

This only has the changes that seem clearly right.  I'll send a separate 
message about the trickier parts of the ABI baseline.

diff -ruN nptl-fpu/libc.abilist nptl/libc.abilist
--- nptl-fpu/libc.abilist	2012-05-16 12:42:09.552250925 -0700
+++ nptl/libc.abilist	2012-05-16 14:00:26.162292503 -0700
@@ -2065,7 +2089,36 @@
  wctype_l F
 GLIBC_2.3.2
  GLIBC_2.3.2 A
+ __adddf3 F
+ __addsf3 F
+ __divdf3 F
+ __divsf3 F
+ __eqdf2 F
+ __eqsf2 F
+ __extendsfdf2 F
+ __fixdfsi F
+ __fixsfsi F
+ __fixunsdfsi F
+ __fixunssfsi F
+ __floatsidf F
+ __floatsisf F
+ __gedf2 F
+ __gesf2 F
+ __ledf2 F
+ __lesf2 F
+ __muldf3 F
+ __mulsf3 F
+ __negdf2 F
+ __negsf2 F
  __register_atfork F
+ __sim_disabled_exceptions D 0x4
+ __sim_exceptions D 0x4
+ __sim_round_mode D 0x4
+ __sqrtdf2 F
+ __sqrtsf2 F
+ __subdf3 F
+ __subsf3 F
+ __truncdfsf2 F
  epoll_create F
  epoll_ctl F
  epoll_wait F
@@ -2108,7 +2161,6 @@
  __chk_fail F
  __fprintf_chk F
  __gets_chk F
- __longjmp F
  __memcpy_chk F
  __memmove_chk F
  __mempcpy_chk F
@@ -2161,6 +2213,10 @@
  __fgetws_chk F
  __fgetws_unlocked_chk F
  __finitel F
+ __floatundidf F
+ __floatundisf F
+ __floatunsidf F
+ __floatunsisf F
  __fprintf_chk F
  __fwprintf_chk F
  __fxstatat F
@@ -2171,11 +2227,17 @@
  __gethostname_chk F
  __getlogin_r_chk F
  __getwd_chk F
+ __gtdf2 F
+ __gtsf2 F
  __isinfl F
  __isnanl F
+ __ltdf2 F
+ __ltsf2 F
  __mbsnrtowcs_chk F
  __mbsrtowcs_chk F
  __mbstowcs_chk F
+ __nedf2 F
+ __nesf2 F
  __nldbl__IO_fprintf F
  __nldbl__IO_printf F
  __nldbl__IO_sprintf F
@@ -2265,6 +2327,8 @@
  __swprintf_chk F
  __syslog_chk F
  __ttyname_r_chk F
+ __unorddf2 F
+ __unordsf2 F
  __vfprintf_chk F
  __vfscanf F
  __vfwprintf_chk F

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: powerpc-nofpu ABI baselines

[Joseph S. Myers]

Now for the trickier differences in the ABI between the fpu and nofpu 
cases.  I would welcome comments on the correct handling of these.

diff -ruN nptl-fpu/libc.abilist nptl/libc.abilist
--- nptl-fpu/libc.abilist	2012-05-16 12:42:09.552250925 -0700
+++ nptl/libc.abilist	2012-05-16 14:00:26.162292503 -0700
@@ -267,7 +267,6 @@
  _libc_intl_domainname D 0x5
  _longjmp F
  _mcleanup F
- _mcount F
  _nl_default_dirname D 0x12
  _nl_domain_bindings D 0x4
  _nl_msg_cat_cntr D 0x4

This is bug 14042, applying to nofpu as to fpu.  Clearly this change 
should not be made to the checked in baseline.

@@ -1845,6 +1844,31 @@
  __xpg_sigpause F
  __xstat64 F
  _flushlbf F
+ _q_add F

[...]

See <http://sourceware.org/ml/libc-ports/2007-10/msg00004.html>.  These 
functions are in GLIBC_2.2 version but would not have been in glibc 2.2 
and would never actually have been useful.  Do we want to record them as 
part of the GLIBC_2.2 ABI to preserve, or remove them?

diff -ruN nptl-fpu/libm.abilist nptl/libm.abilist
--- nptl-fpu/libm.abilist	2012-05-16 12:42:09.552250925 -0700
+++ nptl/libm.abilist	2012-05-16 14:00:26.162292503 -0700
@@ -163,7 +163,6 @@
  __clog10l F
  __fe_dfl_env D 0x8
  __fe_enabled_env D 0x8
- __fe_nomask_env F
  __fe_nonieee_env D 0x8
  __finite F
  __finitef F

This really was in libm as of 2.5.  My guess is that it disappeared as a 
result of:

2007-04-30  Steven Munroe  <sjmunroe@us.ibm.com>
            Peter Bergner  <bergner@us.ibm.com>

[...]
        * sysdeps/unix/sysv/linux/powerpc/powerpc32/fe_nomask.c: Moved to...
        * sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/fe_nomask.c: ...here.
[...]

and

2007-07-13  Steven Munroe  <sjmunroe@us.ibm.com>

        * sysdeps/powerpc/nofpu/Makefile: Remove fe_nomask from libm-support.

It wouldn't actually have worked for nofpu.  Should we keep the removal 
from the GLIBC_2.1 ABI, or add back a stub version that sets errno to 
ENOSYS (i.e. includes sysdeps/powerpc/fpu/fe_nomask.c, which does just 
that)?  (Note that sysdeps/powerpc/bits/fenv.h - shared by fpu and nofpu 
configurations to facilitate multilib configurations - declares both 
__fe_mask_env and __fe_nomask_env.  But __fe_mask_env is in no Versions 
file so will not be exported from libm for fpu configurations either.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: powerpc-nofpu ABI baselines

[Roland McGrath]

> @@ -1845,6 +1844,31 @@
>   __xpg_sigpause F
>   __xstat64 F
>   _flushlbf F
> + _q_add F
> 
> [...]
> 
> See <http://sourceware.org/ml/libc-ports/2007-10/msg00004.html>.  These 
> functions are in GLIBC_2.2 version but would not have been in glibc 2.2 
> and would never actually have been useful.  Do we want to record them as 
> part of the GLIBC_2.2 ABI to preserve, or remove them?

The relevant question is when the bug came in such that _q_add was
exported.  If it has been that way for some widely-used versions, then
it's likely that there are binaries referring to the symbol.  In that
case, we can't really take it out even though it's an inaccurate
representation of what 2.2 was.

Re: powerpc-nofpu ABI baselines

[Joseph S. Myers]

On Wed, 16 May 2012, Roland McGrath wrote:

> > @@ -1845,6 +1844,31 @@
> >   __xpg_sigpause F
> >   __xstat64 F
> >   _flushlbf F
> > + _q_add F
> > 
> > [...]
> > 
> > See <http://sourceware.org/ml/libc-ports/2007-10/msg00004.html>.  These 
> > functions are in GLIBC_2.2 version but would not have been in glibc 2.2 
> > and would never actually have been useful.  Do we want to record them as 
> > part of the GLIBC_2.2 ABI to preserve, or remove them?
> 
> The relevant question is when the bug came in such that _q_add was
> exported.  If it has been that way for some widely-used versions, then
> it's likely that there are binaries referring to the symbol.  In that
> case, we can't really take it out even though it's an inaccurate
> representation of what 2.2 was.

The symbols came in when glibc was built with a compiler supporting 
128-bit long double.

If versions before 2.4 were built like that, the result would be entirely 
ABI-incompatible with any current libc; it's 2.4 that got the proper 
support for 128-bit long double on powerpc, with all the affected 
functions having GLIBC_2.4 symbol versions for the versions using 128-bit 
long double so that older binaries built with 64-bit long double continue 
to use older versions of functions built for 64-bit long double.  So we 
can consider the symbols to have come in at version 2.4.

In glibc 2.4, sysdeps/unix/sysv/linux/powerpc/configure.in ensures that 
128-bit long double is supported and ensures that glibc is built with 
-mabi=ibmlongdouble (and sysdeps/ieee754/ldbl-128ibm/Makefile ensures 
-mlong-double-128 is used).  The ABI since 2.4 has been the use of 128-bit 
IBM long double.

The _q_* functions, however, are helper functions for IEEE quad long 
double.  GCC will only ever generate calls to them if 
-mabi=ieeelongdouble.  -mabi=ieeelongdouble is entirely ABI-incompatible 
with IBM long double, as used in glibc 2.4 and greater.  Since the 
functions in question are not built with -mabi=ieeelongdouble, they do not 
even provide the correct interface for any object built with 
-mabi=ieeelongdouble (IEEE quad long doubles being passed by reference); 
calls to them would never have done anything useful.

The function _q_utoq, to which GCC might generate calls with 
-mabi=ieeelongdouble, is listed in Versions but not exported because the 
source file calls it _q_uitoq.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: powerpc-nofpu ABI baselines

[Roland McGrath]

That's either a rehearsal of your absurdist comedy routine for nerds,
or adequate rationale for dropping the symbols and not looking back.
In fact, I think it's both.