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

Re: [Patches] Differences between glibc and EGLIBC

On 7/4/13 4:56 PM, Joseph S. Myers wrote:

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).
Are 8xx processors still being actively used with new versions of glibc? I'm guessing the answer is no on this. So bringing forward a workaround is fine, but I'm really not sure that there are any users. 


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).
If a copyright assignment can't be done. Then someone needs to re-invent this. Having ldd require bash is just wrong, especially for embedded systems. 


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.
I saw your other message on this. The one question I had was, previously were any of the SPE 'registers' used for passing data? If not, then I agree with the approach -- stick with the soft-float ABI and keep the e500 optimizations internal.
I hope that soon, the e500 will go the way of the 8xx parts of simply be phased our for newer designs... but we're still seeing requests for e500v2 support. 


    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.)
I still think cross-localedef is needed. My users won't be able to (or want to) build a newer glibc for their host, just to generate localedef for their target.
Keeping the localedef as something that can run externally of the glibc build itself is highly useful. My only concern is keeping it external also makes it more of a maintenance issue. 


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*).
There are still people using this. But I agree, the behavior is becoming less and less important. It may be that this type of optimization/mapping become deprecated in a similar way to the option groups that were discussed previously.
I think the two biggest users are debian (I assume they still use it), and OpenEmbedded. (Where I know there are cases where mklibs doesn't work properly.) 

--Mark


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.



_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches