[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] Differences between glibc and EGLIBC
- To: <patches@xxxxxxxxxx>
- Subject: Re: [Patches] Differences between glibc and EGLIBC
- From: Mark Hatle <mark.hatle@xxxxxxxxxxxxx>
- Date: Mon, 8 Jul 2013 11:28:44 -0500
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
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
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
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
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
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
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
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
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.)
14. Extra test debug/tst-backtrace6 (may need new interfaces for a
test of this functionality to pass reliably, see discussion
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