On Mon, 8 Jul 2013, Mark Hatle wrote:
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.
I've no idea whether such processors are being used or not.
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.
There are no updates in copyright.list at all since 2 June. I think it's
fair to suppose that the assignment was indeed sent in, but that the
person processing assignments is on holiday / off sick.
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.
The SPE registers are only used for argument-passing of SPE vector types,
which is not relevant to any glibc function. Apart from that, the
argument-passing ABI is already the same as soft-float; the differences
are just about the SPE PIM functions, symbol versions and FE_* exception
macro values as I described in
<http://www.eglibc.org/archives/patches/msg01291.html>.
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.
The external build is a massive pain to maintain and frequently breaks on
merges from glibc. The tool itself doesn't change much (so if you have an
EGLIBC-based host distribution, e.g. Debian or Ubuntu, it's quite possible
the installed host localedef will work for processing locales for the
target, given an appropriate endianness option).
The present approach of reaching over to use source files not designed for
use outside the main glibc build is not sustainable. To keep
cross-localedef long term as something that can be built separately from
glibc, someone needs to put in the (probably weeks of) work to separate
localedef and other host tools from the glibc source tree, into separate
git repositories on sourceware, so that the standard build is always using
an installed glibc rather than as part of building glibc. (Then one could
consider how much portability to hosts with older glibc - or non-glibc
hosts - is needed, and maybe use gnulib to provide that portability in the
separate localedef package.)
The options for endianness and wchar_t alignment are the only parts I
consider critical to merge to glibc before the separate EGLIBC source tree
is declared dead. (I want to deal with some of the other patches in the
list as well before declaring the separate source tree dead. But I also
think we might reasonably set a goal for 2.19, in six months' time, to be
the last release branch of the separate source tree, with anything
remaining unmerged by then being discarded in the absence of users caring
enough about it to merge to glibc.)
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.)
Would someone from one or the other of those users like to pick up merging
this into glibc, then? (It would be a good idea to complete the copyright
assignment paperwork first, given that it's quite likely any patch
submitted needs a substantial rework.)