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

Re: [Patches] Differences between glibc and EGLIBC

Here is a further updated (and with more details on some individual
entries) version of my list
<http://www.eglibc.org/archives/patches/msg01261.html> of changes
between glibc and EGLIBC that should be got into glibc (possibly in a
reworked form not based on the original patch, but implementing the
desired features) or reverted from EGLIBC if they no longer serve a
useful purpose (to emphasise: the presumption is that the source trees
should converge and *no* major differences should stay in the EGLIBC
source tree long term).  It would still be useful for more people to
help picking up patches and working on getting the associated features
into glibc.


Miscellaneous changes (that should not be too much effort to get in)
include the following (as usual, look at the current version in EGLIBC
after merges from upstream and any bugfixes made in EGLIBC, which may
differ from the originally committed version).  In some cases, if it
can clearly be justified that the change is no longer relevant, it
should be reverted.

1. powerpc 8xx cache line workaround (r2503).

2. Robustness for ldd with non-bash shells (really only makes sense if
   properly converted to be a POSIX shell script).  Patches making ldd
   a POSIX shell script, and generally avoiding $"" in installed
   scripts (glibc bug 13853), were posted to libc-alpha in November
   2012, but will need a copyright assignment to be completed before
   they can go in; that was apparently
   <http://sourceware.org/ml/libc-alpha/2013-06/msg01150.html> sent in
   June 2013, but hasn't yet appeared in copyright.list (as of
   2013-07-04).

3. Avoid __block identifier (I think __glibc_reserved_block would meet
   the agreed convention now).

4. resolv.conf timestamp checks (note multiple followup fixes);
   originated in a SUSE patch.


Changes that are likely to involve more work (maybe substantial
reworking) or be more controversial include the following.

5. Option group support.  (I think Carlos once expressed an interest
   in this, at least as regards the option groups corresponding to
   POSIX profiles.)  Any submission of this should take into account
   Steve Longerbeam's patches that didn't get checked in - that is,
   start by locating the final versions of those patches, retesting
   them, writing proper GNU ChangeLog entries for them and
   resubmitting them.  Then start from the resulting version of option
   group support (probably one option group at a time).  (See
   <http://www.eglibc.org/archives/patches/msg01049.html>.  Khem Raj
   expressed an interest in this merge.)

   As per discussion starting at
   <http://www.eglibc.org/archives/patches/msg01268.html>, it may be
   appropriate in six months to a year to consider deprecating and
   removing this feature.  But until then, fixes for actual bugs in
   existing option group code should be submitted as usual, and
   merging Steve Longerbeam's patches would also still be welcome.
   Note however that as I said at
   <http://www.eglibc.org/archives/patches/msg01284.html>, certain
   option groups do not make sense and should be removed.

6. e500 port.  I thought for a while that this should involve
   rearranging powerpc32/fpu/ files in glibc in a similar way to the
   m68k port, to reflect the different incompatible floating-point
   implementations for the architecture.  But while that makes a
   certain logical sense, there's much less in common between the two
   than there is between the m68k FPU variants.  So my preferred
   option now is as described at
   <http://www.eglibc.org/archives/patches/msg01286.html>: treating
   the port as an optimized variant of soft-float powerpc and making
   it use exactly the same ABI as soft-float powerpc.

   The ABI implications of such a change for existing binaries
   (executables and shared libraries) are detailed at
   <http://www.eglibc.org/archives/patches/msg01291.html> (in
   principle a binary or shared library could be affected without
   using one of those symbols, e.g. by having a variable initialized
   to one of the FE_* exception macros and passing it to another
   shared library that uses one of the affected functions, but that
   seems very unlikely in practice).

   The SPE PIM functions would move into a separate library libspe (as
   they were in Aldy's add-on).  The implementations use some of the
   MPN functions, like strtod does, so the library would naturally be
   a glibc add-on that could pick up the relevant objects also used in
   libc.so, or the symbols could be exported at GLIBC_PRIVATE from
   libc.so (I can see possible use for these functions in libm in
   future as well).  Such an add-on might or might not be in the glibc
   repository.

7. Making --disable-versioning work.  A similar question applies as
   for option groups as to whether this is still useful (either the
   fixes should be merged to glibc, or the option should be completely
   removed).

8. Cross-localedef.  (Multiple parts; maybe the support for options to
   localedef to specify endianness and uint32_t alignment would be the
   least controversial, and also the largest so most valuable to
   merge.  It's not clear if support for non-glibc hosts is useful any
   more or whether it would be sufficient for cross-localedef users to
   build the relevant glibc version for their host and then run the
   new localedef with the new glibc, so support for building out of
   the glibc build tree wouldn't be needed.)

9. SH __fpscr_values.  In general symbols should not be added to old
   symbol versions, but there's a question here of whether actually
   most or all SH glibc users are in fact using glibc with this patch
   so it is part of the de facto ABI.  See
   <http://sourceware.org/ml/libc-alpha/2012-05/msg01988.html>.

10. bits/predefs.h to allow __STDC_IEC_559__ and
    __STDC_IEC_559_COMPLEX__ to be defined only conditionally
    (possibly should be done through appropriate GCC features instead;
    see a comment in glibc bug 10110 suggesting GCC predefines
    __IEC_559_MACROS_PREDEFINED__ when configured for a target C
    library that intends to implement the relevant library features,
    and then GCC predefines or otherwise the __STDC_* macros depending
    on options such as -ffast-math).

11. ColdFire MMAP2_PAGE_SHIFT.  See
    <http://sourceware.org/ml/libc-ports/2013-06/msg00067.html> for a
    submission of a new version of this patch, and
    <http://sourceware.org/ml/libc-alpha/2013-07/msg00032.html> for a
    fix to the associated libc code.

12. A Linuxthreads manpage change.  Insubstantial, but there's no
    glibc git repository for Linuxthreads (it's never been converted
    from CVS).  It still appears to be the case that the man-pages
    project does not have a manpage for pthread_mutex_init /
    pthread_mutex_unlock (the one in question), and that Linuxthreads
    is being used to provide a manpage for those functions by Ubuntu,
    for example.  I believe it is also the case that Linuxthreads is
    still being used by GNU/kFreeBSD, so if that gets merged to glibc
    then there may be a case for merging in the Linuxthreads history.

13. Installation of *_pic.a and associated .map files for use of
    mklibs.  Same question applies as for option groups and
    --disable-versioning about whether this is still useful (the
    original use case of mklibs having been for boot *floppies*).

14. Extra test debug/tst-backtrace6 (may need new interfaces for a
    test of this functionality to pass reliably, see discussion
    starting at
    <http://www.eglibc.org/archives/patches/msg01077.html>).


There are also a few differences deliberately kept for compatibility
with EGLIBC ways of cross-building and cross-testing, although glibc
now has support for those things in slightly different ways.

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