Re: [Patches] The state of the e500 EGLIBC port

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Tue, 2 Jul 2013, Joseph S. Myers wrote:

> The apparent lack of interest in the e500 port does leave me wondering if 
> it's another feature that should be deprecated, like the proposal to 
> deprecate option groups.  But to the extent that there may still be users 
> for this port, how much do those users care about binary compatibility 
> with past versions?

I should perhaps clarify what the ABI differences from standard soft-float 
powerpc glibc are, since most binaries may not be affected by a move to 
the standard soft-float powerpc glibc ABI.  First, comparing e500v2 and 
soft-float glibc:

* The e500 port removes (accidentally) various (mainly compatibility) 
symbols that are present in soft-float glibc (libc and libm).  For e500v2, 
it also does not have the various soft-fp symbols.  This should not affect 
compatibility with any binaries built with the e500v2 port (extra symbols 
appearing if the ABI changes to the normal soft-float ABI should be 
harmless to existing binaries).

* The e500 port adds the SPE PIM string to fixed-point symbols atosfix16 
atosfix32 atosfix64 atoufix16 atoufix32 atoufix64 strtosfix16 strtosfix32 
strtosfix64 strtoufix16 strtoufix32 strtoufix64 to the shared libc.  Any 
binaries using those would be broken by a move to the standard ABI (so 
moving those functions out to a separate library).

* The e500 port adds a symbol __fe_nomask_env to libm that is not in the 
standard soft-float glibc, and uses it in defining FE_NOMASK_ENV.  So any 
binaries using the symbol __fe_nomask_env (via source code using 
FE_NOMASK_ENV) will be broken - but note that in any case this function is 
a stub that sets errno to ENOSYS so uses of it may not have done anything 
much useful.

* The <fenv.h> bits representing floating-point exceptions are different 
in the two ABIs.  Thus, any program using any of the following libm 
functions would be broken by a change: feclearexcept fegetexceptflag 
feraiseexcept fesetexceptflag fetestexcept feenableexcept fedisableexcept 
fegetexcept.  (The rounding mode macros are unchanged.)  I'm not sure the 
kernel emulation support has ever been good enough for this functionality 
to work particularly reliably on e500.

Now for e500v1:

* The e500v1 libc has various soft-fp symbols exported, but at different 
symbol versions from in the soft-float libc, so any binaries using those 
(and normally I'd expect programs to get them from libgcc rather than 
libc) would break.  The affected symbols are: __adddf3 __divdf3 __eqdf2 
__extendsfdf2 __feraiseexcept_soft __fixdfsi __fixunsdfsi __floatsidf 
__gedf2 __ledf2 __muldf3 __negdf2 __sqrtdf2 __subdf3 __truncdfsf2 
__floatundidf __floatunsidf __gtdf2 __ltdf2 __nedf2 __unorddf2.


I hope this is enough information for any distributors using the e500 port 
to assess what the impact would be of it changing to use the standard 
soft-float ABI as part of merging into glibc, by examining the symbols 
used from shared libraries by their binaries.  (As a reminder, any 
significant differences between glibc and EGLIBC should go away - the 
question is just whether something is reverted, or merged in some form 
into glibc, and in what form if so - and normal practice when new ports 
merge into glibc is that they get all-new symbol versions, so GLIBC_2.19 
for all symbols for anything merging in between the 2.18 and 2.19 
releases.  In this case, I think it's more natural to treat the e500 port 
as an optimized variant of the soft-float port, so using the same symbol 
versioning as that port.)

In short: affected binaries would use one or more of the following libc 
symbols: atosfix16 atosfix32 atosfix64 atoufix16 atoufix32 atoufix64 
strtosfix16 strtosfix32 strtosfix64 strtoufix16 strtoufix32 strtoufix64, 
or (e500v1 only) __adddf3 __divdf3 __eqdf2 __extendsfdf2 
__feraiseexcept_soft __fixdfsi __fixunsdfsi __floatsidf __gedf2 __ledf2 
__muldf3 __negdf2 __sqrtdf2 __subdf3 __truncdfsf2 __floatundidf 
__floatunsidf __gtdf2 __ltdf2 __nedf2 __unorddf2, or one or more of the 
following libm symbols: __fe_nomask_env feclearexcept fegetexceptflag 
feraiseexcept fesetexceptflag fetestexcept feenableexcept fedisableexcept 
fegetexcept.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches