Re: [Patches] The state of the e500 EGLIBC port (original) (raw)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

• To: <patches@xxxxxxxxxx>
• Subject: Re: [Patches] The state of the e500 EGLIBC port
• From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
• Date: Thu, 4 Jul 2013 13:26:34 +0000

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

• References:
  • [Patches] The state of the e500 EGLIBC port
    * From: Joseph S. Myers
• Prev by Date:[Patches] Update e500 localplt baselines
• Next by Date:Re: [Patches] Differences between glibc and EGLIBC
• Previous by thread:[Patches] The state of the e500 EGLIBC port
• Next by thread:[Patches] e500 port fixes and cleanups
• Index(es):
  • Date
  • Thread