• Development_Todo
• Master

Master Todo List

This is the master TODO list for the project all other TODO lists reference this list.

Smaller self-contained projects, where it is readily possible to assess whether theenhany are completed and where it is uncontroversial what should be changed, should generally go in Bugzilla. Projects here may be less precisely defined and may not always have consensus on whether there is a genuine problem and how it should be fixed.

Documentation

It's always good to start by writing documentation. It helps you learn the API and understand what problems real users face day-to-day when working with the interface.

• The README file in git needs some cleanup to update the lists of supported systems in libc and ports

• Clean up the FAQ.

• move the PROJECTS file from git to wiki - and remove obsolete entries.
• WUR-REPORT is similarly a projects list that should be merged into this page.
• Likewise, the nptl/TODO* files.
• Some functions that are documented in the manual as "GNU" are now in newer versions of ISO C or POSIX; the documentation should be updated accordingly.
• The installation documentation needs further review and updating (especially as regards the minimum versions of some tools documented as supported).

• Clean up and update maint.texi, especially the descriptions of makefile variables and the example lists of sysdeps directories.

POSIX Threads

At present the glibc manual has *no* pthread documentation, and we need to fix this. The complete project is large, but it should be broken up into chunks, each chunk doable in a quick sit-down hacking session.

• Documenting the glibc pthread API.
  • Add a new section to the manual for pthreads.
  • Document one function from pthreads in the new pthreads section in the manual.
  • Add an example to one pthreads function in the manual.

Please note that you must not copy from other sources and for copyright purposes this must be your own work.

We should coordinate with linux man pages project.

Missing Functions

There are some functions that were added to glibc but not documented. We need to find them.

Again this work is incremental, find a function, add it to the manual.

• Find a public function that was added and not described in the manual.
• Document the public function in the manual.
• Add a man page to the linux man-pages project if it doesn't have one already.

Please note that you must not copy from other sources and for copyright purposes this must be your own work.

• scripts/documented.sh can be used to find undocumented functions. First, it needs to be updated to reflect the current set of libraries built by glibc (the script currently refers to Linuxthreads, for example). It should also not include an individual email address in the output. Then, the output could be made available somewhere (linked from the wiki), or used to file bugs.
• Note that documented.sh only covers functions, and it would be good to have such an automatic search for undocumented public macros as well.
• If a list of known undocumented interfaces were in the sources, it might be possible to make the addition of any new undocumented interfaces result in a build or testsuite failure.

Internals documentation

• Document how to debug your application from dynamic loader all the way to the application main.
  • Start by debugging the dynamic linker.
  • Progress to loading the symbol file for your application at the correct offset.
• Update wiki:
  • Include "What do I need to file a locale change?"
• Create a glibc internals manual seperate from the user manual
  • Internals manual will cover makefile targets and porting.
  • Move appending porting info from user manual to internals manual.

Bugs

There are many bugs in the bug database for product=glibc. We need help managing these bugs.

• move the BUGS file from git to bugzilla (one bugreport for each entry) - and check that the bugs are valid
• Systematically review open bugs to ensure they are valid, still present in current glibc and that all the Bugzilla fields are set correctly (including removing default assignments). This was done by Joseph for open "ports", "linuxthreads", "math" and "soft-fp" bugs already.
• Help fix bugs in glibc!
• Tests marked as XFAIL in the glibc testsuite (make check) have a bug associated with them in bugzilla. Some of these may be good targets to get started with contributing to glibc given that there is already a test case that you can step through and take apart.

Reproducing

We need help reproducing bugs. We need to know if they are real and if they apply to trunk.

• Pick a bug that is in the NEW or UNCONFIRMED or REOPENED state, or a SUSPENDED or ASSIGNED bug that hasn't been touched recently.
• Try to reproduce the bug.
• If you succeed at reproducing the bug you should:
  • Describe the steps to reproduce it if they are different from the submitters instructions.
  • Update the "Last Reconfirmed" date with the date on which you reproduced the bug.

  • See Bug_Triage and Bugzilla Procedures for more details. You don't need to do everything listed there; any bit of work on reproducing a bug is useful.

Testing

Infrastructure

• Improve the support for generating a log with PASS or FAIL results for individual tests.
  • Tests not supported (e.g. requiring a function or other feature not implemented on the particular architecture) should show as UNSUPPORTED in the logs.
  • There should be a standard way of handling tests that are only partly supported, e.g. that can test some but not all things if floating-point exceptions or rounding modes are not supported. This should make it readily visible that parts of the test have not been run, in case the unsupported feature *should* have been supported on the given architecture.
  • Tests should show as UNRESOLVED in cases such as insufficient memory.
  • Compiling / linking a test should produce results separately from running it.
  • Tests that are expected to fail should show as XFAIL (or XPASS, if they pass).

  • See http://sourceware.org/ml/libc-alpha/2012-09/msg00439.html for more regarding test statuses.

  • When a test depends on another test, failure in the dependency should cause the depending test to return UNRESOLVED, not FAIL or PASS.
• Support for testing an installed C library without needing its build tree to be available.
  • For this, some tests such as tst-xmmymm.sh or check-local-headers.sh that fundamentally depend on the build tree would need to be run with a separate makefile target from the build tree, since they could not be run at "make check" time.
  • Tests with lesser build-tree dependence might require an option to install some files from the build tree that are only actually needed for testing.

• Describe more features of tests through annotations in "tests" or a per-test variable listing test properties, as suggested in http://sourceware.org/ml/libc-alpha/2012-09/msg00276.html

• See https://sourceware.org/ml/libc-alpha/2013-07/msg00256.html for various cross-testing issues.

• Develop a policy for architectures to mark tests as expected to fail in their sysdeps makefiles, so providing more structured information about such expectations (which presently goes on per-release wiki pages and distributions' own tracking systems for expected failures) and reducing the need for duplicating such tracking for each release and distribution. We might want rules such as requiring such system-specific XFAILs to have a comment referring to a GCC or glibc bug, with the GCC or glibc bug having a mention of the XFAIL, and include a review of XPASSes in the things architecture maintainers should do for each release, to see if any such expectations of failure can be removed.

Untested interfaces.

• All public interfaces should be tested by the testsuite as far as possible (some may require root access or otherwise be problematic to test).
• It would be good to have an automatic search for untested interfaces, possibly like scripts/documented.sh (see above) for undocumented interfaces.
• Addition of tests for any untested interface is a useful contribution. ldiv, lldiv and imaxdiv are examples of untested interfaces - tests would have shown up imaxdiv being broken on alpha for a long time.

• See http://sourceware.org/ml/libc-alpha/2013-07/msg00386.html for a list of untested interfaces and some automation for finding them.

• There should be a test that the inttypes.h format macros match the corresponding typedefs. See message.

Test IFUNC implementations.

• Extend framework of testing IFUNC implementations on target to math functions, similar to string function tests:
  • Extract IFUNC test framework from string/test-string.h to test-ifunc.h.
  • Use FOR_EACH_IMPL and CALL to test each IFUNC implementation of math functions.

• Track and report untested IFUNC implementations (see commit 11dd4af and this this email for details).

We need help testing releases.

• Go to the release page.

• Pick a release from the "Current Branches" list.
• Checkout the release, build it, and run the testsuite.
• Under the releases page create a section titled "User-submitted Testsuite Failures"
• Describe your configuration and the failures, it should look like this in markup:

== User-submitted Testsuite Failures ==

User: Carlos O'Donell <carlos@systemhalted.org>
Build system: Ubuntu 11.04, x86, GCC 4.5.2, Binutils 2.21.0, Kernel 2.6.38-8-generic (32-bit).
{{{
make[2]: *** [/home/carlos/build/glibc-2.15/localedata/tst-xlocale1.out] Error 1
make[1]: *** [localedata/tests] Error 2
make[2]: [/home/carlos/build/glibc-2.15/posix/annexc.out] Error 1 (ignored)
make[2]: *** [/home/carlos/build/glibc-2.15/rt/tst-cpuclock2.out] Error 1
make[1]: *** [rt/tests] Error 2
make[2]: *** [/home/carlos/build/glibc-2.15/elf/tst-unique3lib.os] Error 1
make[2]: *** [/home/carlos/build/glibc-2.15/elf/tst-unique3lib2.os] Error 1
make[2]: *** [/home/carlos/build/glibc-2.15/elf/tst-unique3.o] Error 1
make[2]: *** [/home/carlos/build/glibc-2.15/elf/tst-unique4.o] Error 1
make[2]: *** [/home/carlos/build/glibc-2.15/elf/check-localplt.out] Error 1
}}}

Use test-skeleton.c

• Migrate all tests to use the top-level test-skeleton.c
  • Add a TEST_DIRECT so that tests which test fork are not forked by test-skeleton.c.

  • Some work is already underway. Read this and this for details.

• Fix test-skeleton.c to support tst-initializers1 tests and similar which fail with:

In file included from ../malloc/malloc.h:24:0,
                  from ../include/malloc.h:2,
                  from ../test-skeleton.c:22,
                  from tst-initializers2.c:54:
../include/stdio.h:111:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__getwc_unlocked’
cc1: warnings being treated as errors

• Possibly test-skeleton.c should be split into a part always built with _GNU_SOURCE, built once and linked into all tests, and a minimal part that can be included in tests built for other standards.

• Review uses of add_temp_file in tests. Temporary files should be created in the preparation part of a test (do_prepare rather than do_test) where possible so that they are deleted in the case of abnormal termination in the TEST_DIRECT case. In the common case where files are created with mkstemp, moving to creation with create_temp_file, which deals automatically with registering the files with add_temp_file, is a good idea. Uses of create_temp_file also need to be reviewed for being in the preparation part of tests where possible.

conformtest improvements

• Merge stdlib/isomac and posix/annexc into conformtest and then remove the separate tests, and with them $(native-compile). The first needs ISO C90 Amendment 1 support in conformtest; the second is more confused about what it is testing, but review of the existing "POSIX" (POSIX.1, 1996 edition) support, together with new support for POSIX.1-1990, would cover it.
• In general the expectations need reviewing against relevant standards; this has only been done so far for the ISO C standards supported and for "POSIX".
• Macro expansions (including for functions that may be defined as macros) should be checked to verify that their results are within the reserved namespace.

• There should be tests for __asm__ redirects (implemented via the __REDIRECT macros) that send functions to non-reserved names (see bug 14106).

• There should be tests for #if conditions in headers using non-reserved names.

• Tests should be run (maybe not by default, but optionally, with some people checking the results) for modes such as -O2, -D_FORTIFY_SOURCE, -D_FILE_OFFSET_BITS=64, -ffinite-math-only and 64-bit long double where applicable, to verify that the headers still conform in those modes.

• It would also be useful to run the tests with allow directives disabled for patterns matching symbols the relevant standards reserve but do not define, since glibc policy is generally not to make such symbols (e.g. str* in <string.h>) visible when not required.

• There should be support for testing the exact expansion text of a macro (then such assertions should be added where relevant standards define what the expansion text should be).

• Consider more precise conventions for associating bugs with xfailed tests - see https://sourceware.org/ml/libc-alpha/2015-06/msg00700.html

Miscellaneous testsuite issues

• The c++-types tests should cover more types from more headers (preferably, every typedef glibc provides as a public interface, since any such type could be used in C++ code and needs a stable ABI there).
• Cover more standards in the linknamespace tests.

• Each installed header should be tested with each feature test macro; either a #include of the header should compile OK, or it should produce a #error error, but not some other kind of error. Also test with -pedantic -Wsystem-headers and different -std= options; as far as possible, no warnings should be produced by the headers in any case.

• Refactor the rules for *-cmp.out tests into more generic support for the case of comparing test output against a baseline. (Some baselines are *.exp, some *.expect, some directly embedded in the makefiles, and nptl/tst-cleanupx0.expect appears unused.)

• Review test rules for any that use && or multiple commands, and refactor them as far as possible to use separate makefile rules for the separate commands where they meaningfully test separate things (for example, any comparisons of output that haven't already been split like this).

• Migrate toplevel tests into subdirectories, further simplifying the toplevel tests rule along the lines of the xtests rule. See https://sourceware.org/ml/libc-alpha/2014-03/msg00152.html for more discussion of this.

• If a test can only be run conditionally, the additions to the tests and tests-special variables are conditional in the makefiles, but whether the makefile targets that say how to run such a test are also conditional varies. Change things so that systematically it's only the additions to those variables that are conditional (seek consensus on such a policy first).

• The entries in tests-special are the full makefile targets, complete with $(objpfx). It should be possible to arrange things so that $(objpfx) isn't included.

• Establish a convention for naming source files used only in testing. Possibly use a test/ subdirectory of each directory, for all files used only for tests (including putting sysdeps files used only for tests in test/ subdirectories of sysdeps directories, though this would make the paths to abilist baselines even longer), and likewise in object directories.

• Make check-abi targets generate and combine .sum files. See message.

• Tests are generally built with internal headers and with _LIBC defined. As far as possible, tests should be built using only the headers that get installed and without _LIBC defined, so they test something closer to how the installed libraries would be used. (At present, tests can define _ISOMAC if they need to disable most internal header contents.)

Benchmarks

There are currently benchmarks for a variety of libm functions and string functions in the benchtests directory.

• A wider array of benchmarks is needed to make sure performance regressions are not introduced. For example, more math functions, more string functions, crypo, atoi, rand, qsort, malloc.
• The existing string benchmarks can be improved in several ways:
  • The alignments tested are not very useful. Generally the interesting cases are 1, 2, 4, 8, 16, 32, 64 and anything in between is a variation in practical terms.
  • The number of function calls per benchmark should be adjusted to provide reasonably low variance and reasonable running time. At the moment there are probably too few calls (too high variance).
  • The performance of memcpy in particular can be affected by physical page placement when using a physically indexed cache (reads and writes contending for the same cache set) which should be controlled for.
  • The benchmarks currently only output the mean execution time but do not give any measure of variance or min/max.
  • There is no mechanism for showing the output of the benchmarks graphically.

Cross build / test improvements

There are still at least the following issues with getting full feature parity of native and cross builds of glibc:

• localedef can only be built as part of a glibc build. "make localedata/install-locales" uses the newly built localedef program and can only be used when building natively. It is possible to set up build infrastructure for building localedef outside of glibc, so that it could be built and used in much the same way as a cross-compiler, although it does make fairly heavy use of glibc features and is not that easy to make build on a wide range of systems.
• The conform/ tests are only enabled for native building. They build programs using new headers but not linked with the new C library (linked with whatever one the compiler uses by default - which may of course not exist / be installed in the case of a cross compiler), and then run such programs. They would probably need changing to link properly with the new library, and run programs the way programs built with it should be run, so using $(run-program-prefix) - ideally supporting doing just compilation and not execution tests if $(run-built-tests) is "no". Many tests that currently execute could actually be implemented as compilation tests (where testing values of constants).
• iconvdata/Makefile and sysdeps/s390/s390-64/Makefile try to update an existing gconv-modules.cache file, for native builds, using the newly built iconvconfig. Some form of cross-iconvconfig would be needed to generate / update such a file in general for cross builds.

• The toplevel Makefile runs ldconfig for native builds. Cross-ldconfig is, like cross-localedef, something potentially of use when cross-building a system's root filesystem image. A version was once implemented at CodeSourcery for an old glibc version; the target dependencies are substantially more complicated than for ldconfig, so it may not readily be possible to make an ldconfig binary work generically for all architectures, and as with localedef the code has a lot of glibc dependencies so portability to a range of build systems may also be hard.

• malloc/Makefile disables memusagestat when cross-compiling: "Unless we get a test for the availability of libgd which also works for cross-compiling we disable the memusagestat generation in this situation.". It should be possible to implement such a test - it wouldn't work in bootstrap situations, but could be used if a glibc build has been installed, then libgd built against that installed glibc, and now glibc is being built again. But really this is a program that should be split out into a separate package (glibc-memusage, or glibc-utils) - released alongside glibc, maybe, but built on its own after glibc is built and installed.

Date and Time API

MT-Safe and TZ-aware functions

The problem is that you're running a multithreaded server and you want to output a time stamp in the client's time zone. With glibc, that's a pain, since the TZ setting is process-wide, and if one of your threads sets TZ='Europe/Moscow' (say), then all your threads are affected. The reference implementation of the Time Zone Database addresses this by having four new functions declared in <time.h>:

• tzalloc accepts a string like "Europe/Moscow" and returns a newly allocated object of type timezone_t that represents the rules for the named time zone.

• tzfree frees a timezone_t object.

• localtime_rz is like localtime_r except with a timezone_t argument prepended.

• mktime_z is like mktime except with a timezone_t argument prepended.

This API is derived from a more-complex API in NetBSD. NetBSD is intending to switch to match the simpler reference API. It is not known if there are any other systems with these primitives other than Minix 3, which uses this part of NetBSD userland.

Distribution merging

It is desirable to merge in changes from the various distributions of glibc or files based on glibc and to reduce divergence between those versions.

• EGLIBC - see http://www.eglibc.org/archives/patches/msg01327.html for a list of differences from glibc.

• gnulib (for the files originating in glibc, the aim should be that there are no differences other than those to license notices and the use of spaces in gnulib instead of TABs that follow from gnulib policy).
• GNU Hurd (out-of-tree changes required for fully-functional glibc)
• Fedora

• SUSE - current package is at https://build.opensuse.org/package/show/Base:System/glibc

• Debian
• Ubuntu

Code Quality

• Use __attribute__ ((nonnull)) more often, both for code documentation and static analysis purposes. Be aware of GCC PR17308.

• Based on the sprof program we need tools to analyze the output. The result should be a link map which specifies in which order the .o files are placed in the shared object. This should help to improve code locality and result in a smaller footprint (in code and data memory) since less pages are only used in small parts.

Security

• Build more of glibc with `-fstack-protector`.

• Start building glibc with `-fstack-protector-strong`.

• Start building glibc with -fsanitize-address and other sanitizers. (See here)

• Fix open security bugs. See Security Process.

• Update glibc programs (especially nscd) to use Linux namespaces.

• Update glibc programs (especially nscd) to use Linux seccomp.

Cleanup

• Add and use macros to do align-up and align-down a value or contents of a buffer: http://sourceware.org/ml/libc-alpha/2012-04/msg00006.html

  • This does not imply that all of the code be changed at once to use such macros. The idea here is to introduce these macros with a change and then mandate their use in future changes.

• Further cleanup of the Linux specific <bits/fcntl.h> headers so that struct flock does not need to be declared for each and every architecture. It should be part of the generic bits/fcntl-linux.h.

• Several other Linux bits/*.h headers should be refactored similarly to how much of bits/fcntl.h went into fcntl-linux.h, to reduce the amount of content in architecture-specific files. This includes at least: ipc.h mman.h (partly done) msq.h sem.h shm.h siginfo.h. In general, a good goal is that architecture-specific files do not contain __USE_* conditionals unless a public API is genuinely architecture-specific; it's better for them to define things in the reserved namespace __* with the architecture-independent header then using them to define the public interfaces.

• The various lowlevellock.h headers should be similarly refactored to reduce duplication and divergence. There are two different styles for how errors from syscalls are handled, but apart from that they are substantially similar.

• Look at refactoring bits/mathdef.h as far as possible as suggested in http://sourceware.org/ml/libc-alpha/2012-02/msg00003.html

• If all targets include a generic x86 version of the file, move that file into generic (since it is) and delete all target versions of the file.
• The abstractions involved in _G_config.h are no longer relevant now libio is only used in glibc not libstdc++; it may be possible to eliminate that header completely, but in any case it involves unnecessary levels of indirection.

• Review existing -Wno- options in makefiles to see if they are still needed, and whether the code in question could be cleaned up to avoid the warnings instead. If needed but the code is maintained in glibc rather than imported from elsewhere, convert to diagnostic pragmas (via the DIAG_* macros) as far as possible.

• bug 14 (closed) identifies some latent bugs in getdents regarding nbytes, which should be fixed or filed as separate bugs in Bugzilla.

• The Makeconfig file contains many variables in the "These are the configuration variables." section that are not in fact variables users should ever configure. That section should contain only variables that it is genuinely appropriate for users to configure. The other variables there should be separated into those that sysdeps makefiles may override but users should not, and those that are not intended to be overridden at all.

• Review cases where code in glibc (including the various programs installed with glibc) uses non-large-files interfaces such as fopen or __open internally, as such uses may mean large files are not supported on 32-bit systems in some cases.

• non-ex-ports architectures should be more like ex-ports architectures regarding putting configuration information in sysdeps files instead of architecture-independent files. Specifically:
  • Architecture cases in elf/sotruss-lib.c.

  • Split up config.h.in (bug 14068).

  • Find a way to avoid architecture cases in libc-abis without duplicating the common parts.
• Develop a consistent policy for handling assertions in glibc code (maybe enable them by default but disable with --disable-assert).

• Unify the code for copyright and bug-reporting messages in miscellaneous argp-using programs installed by glibc, as suggested in http://sourceware.org/ml/libc-alpha/2012-11/msg00261.html

• Existing code shared by various miscellaneous programs installed by glibc (xmalloc and xstrdup) comes from locale/programs, even when the programs have nothing to do with locales. A separate programs toplevel directory for such code might be better.

• Go through all files of ten lines or more without FSF copyright and license notices, and add such notices if the files are in fact FSF copyright or if there are significant FSF-copyright changes to a file that has some other copyright and license notice.

• A 2013-02-19 checkout of the master branch has about 6500 files using License along with the GNU C Library; if not, see, and about 1000 using License along with the GNU C Library.  If not, see. Probably these should be unified, using the standard GNU wording (to be determined).

• Stop using wildcards in symbol names in Versions files (stdlib/Versions and wcsmbs/Versions), instead naming all relevant symbols explicitly.

• Where makefiles use -fexceptions or -fasynchronous-unwind-tables, make them use makefile variables that relate to the logical reason those options are needed (e.g. "may be cancelled"), as described in https://sourceware.org/ml/libc-alpha/2012-11/msg00147.html and https://sourceware.org/ml/libc-alpha/2015-10/msg00569.html - and more generally, develop a way to check for consistency issues where a function using callbacks isn't marked as such, or where a function may be cancelled or uses callbacks but a caller of that function isn't marked accordingly (in some cases that may be OK, however) - and similarly for uses of __THROW etc. in function declarations.

• Where glibc headers include each other with __need_* macros defined, replace that construct with smaller bits/*.h headers with exactly the relevant subset of definitions.

• Remove #if conditionals in glibc relating to __NR_* macros for system calls being defined, where those macros will always be defined (for all architectures using the relevant file) for headers from Linux 2.6.32 and later.

• Use __NR_* directly in Linux-specific .S files, not SYS_* or SYS_ify. See message.

• Review the public ABI for symbols starting with '_' and make them only compatibility symbols, not available for new links, unless there is a good reason they need to be in the public ABI for new links (e.g. use from macros or inline functions in current headers), as described at http://sourceware.org/ml/libc-alpha/2012-12/msg00232.html - this includes the unwinder symbols exported at version GCC_3.0 for old binaries, as well as symbols exported at GLIBC_* versions. All such symbols with a good reason to be in the public ABI for new links should have comments in the Versions files explaining the reason.

• Consider deprecating strfry and memfrob (making them only compatibility symbols) as not useful in practice.

• Convert old-style function definitions to ISO C prototype definitions. It should be possible to script most of such a conversion using heuristics and regular expressions, then add -Wold-style-definition to the default warning options to catch any other cases.

• Cleanup feature macros: The original intent of all the __USE_* macros was that they would always be used singly. That is, all the headers would only ever have simple "#ifdef __USE_FOO" conditionals (never nested), specifically so that features.h is the one and only place where all the complex interrelationships have to be understood (see http://sourceware.org/ml/libc-alpha/2013-04/msg00355.html for more details)

• Review interfaces conditioned on __USE_MISC to see if some should be obsoleted. See message (and some other messages in that thread).

• Use <intprops.h> within glibc for integer overflow checks (see http://sourceware.org/ml/libc-alpha/2013-05/msg00549.html)

• Look for files not used in any configuration (always overridden by more specific files) and remove them unless wanted as generic files. For example, a file in sysdeps/$arch overridden in sysdeps/unix/sysv/linux/$arch might be genuinely generic, or might just reflect the first OS on that architecture to which glibc was ported. Or the sysdeps/unix/sysv/linux/$arch version could be the more generic one (e.g. for bits/endian.h). It might be possible to automate builds for a set of configurations intended to cover all significant variations, then look for files used in none of those builds.

• Build glibc with -Wvla to find uses of variable length arrays, and systematically review them to see if any could have large stack usage depending on function arguments, configuration file contents etc.; such cases need to condition the uses of VLAs to avoid stack overflow, just as uses of alloca must be conditioned. (This includes for function arguments that must result in an error, if that error is guaranteed by the API rather than undefined behavior; for example, very long filenames are known to cause errors with the Linux kernel, but stack allocation still can't be used unconditionally for them.)

• Uses of alloca also need careful review. Any case of non-constant stack usage bounds for a glibc function should be fixed, though cases where the usage is proportional to the number or size of arguments to the function are lower priority than unbounded usage when arguments use only constant stack space.

• __GNUC__ conditionals, except where they are version tests for a version newer than we assume when building glibc, should be removed everywhere except installed headers and source files shared with gnulib (only those places need to consider being built with a non-GNU compiler.

• Where headers test defined __USE_GNU || defined __USE_SOMETHING_ELSE, the __USE_GNU conditional is redundant and should be removed, as __USE_GNU is only defined when features from other standards are enabled as well. Similarly, defined __USE_XOPEN || defined __USE_POSIX can be changed to test __USE_POSIX only, and there may be other such cases.

• Go through configure tests (both in the toplevel configure and in subdirectory configure and preconfigure scripts) and remove tests whose results can be assumed based on the minimum supported GCC and binutils versions (and the associated conditionals on the results of those tests).

• The removal of the bounded pointers code left behind support for many different letters in syscalls.list describing different types of arguments, where the differences had no significance other than to control generated bounds checks. These should be unified with the generic letters for integers and pointers, and more generally a check should be made for any other missed relics of bounded pointers support.

• To support multilib configurations, the set of headers installed for a given combination of architecture and OS should not depend on other details of the glibc configuration; for the generated headers where separate variants are supported, if the headers can indeed vary then abi-variants and default-abi must be set so that configurations where any of the header contents vary get different copies of those headers. Specifically, this is known to be an issue for m68k bits/fenv.h and bits/mathinline.h, but should be carefully checked for other configurations as well.

• Where configure scripts (including in subdirectories) add directly to config_vars, they should use LIBC_CONFIG_VAR instead.

• Eliminate remaining cases of <space><tab> in source files (including after initial indent), unless there is some good reason for this sequence to be present, and of blank lines at the end of source files, and of trailing whitespace (spaces or tabs) on any lines of source files.

• Eliminate remaining uses of register in declaration specifiers, except in source files imported verbatim from other sources and where used to assign a variable to a particular register. In previous discussion it was felt this should include cases where register may have been used to document that a variable was being used as an asm input or output (https://sourceware.org/ml/libc-alpha/2013-06/msg00231.html).

• Where makefiles (including Makerules) use && at the end of a line as part of a multi-line command, move it to the beginning of the next line in accordance with normal GNU style.

• As suggested in https://sourceware.org/ml/libc-alpha/2013-09/msg00789.html, make localedef --help report the default endianness.

• Clean up the issues with libc-abis described in https://sourceware.org/ml/libc-alpha/2014-01/msg00375.html, ensuring that the libc-abis system, including its interaction with binutils, is properly documented.

• Set subdirectory variables to empty in Makeconfig as proposed in https://sourceware.org/ml/libc-alpha/2014-02/msg00520.html and do the associated cleanup of code to override values from the environment. Update the list of such variables in maint.texi in the process.

• Make posix/Makefile append to before-compile instead of overriding the value from Makeconfig.

• Clean up settings of variables such as generated (resolv/Makefile has an apparently unused variable generate), so that make clean after build and testing leaves results the same as after configure and make distclean leaves an empty build directory. The tests-special and xtests-special variables could be used to clean up some test-related files automatically with duplicate references to those files then being removed from generated.

• Make Glibc buildable with Clang. See GlibcMeetsClang

• Various atomics and locking files have conditionals on a macro UP (uniprocessor), which nothing defines. Remove all those conditionals.

• Some files have #ifdef or #ifndef conditionals on macros weak_alias and libc_hidden_def from libc-symbols.h. Such conditionals may be a relic of non-ELF support; they should all be removed. (Watch out however for files undefining those macros before including another file; the normal approach is to undefine then redefine with an empty expansion, but you need to make sure there aren't any cases relying on a conditional in the included file.)

• Review __libc_* and *_internal function aliases / names (in syscalls.list files and elsewhere) and remove those that are no longer used (no callers for those names). Specific cases to look at include _dl_skip_args_internal and __canonicalize_directory_name_internal.

• Remove obsolete linuxthreads references in the source tree.

• Remove USE_REGPARMS and define internal_function in a sysdeps header instead. See message.

• Develop some automation to ensure that include/ declarations of __* function aliases have the same attributes, use of __THROW etc. as the declarations of the corresponding public interfaces, and fix the issues shown up.

• Use typeof where possible for declaring such aliases, with comments when there is some reason the type has to be repeated in the internal header.

• Develop some automation to ensure that internal calls have it visible to the compiler that the function is hidden, and fix cases shown up where it is not hidden. See bug 18822 for the i386 case.

• Review public function declarations for more attributes that should be on them.

Enhancing malloc

Split to separate page

Enhance LD_DEBUG

Split to separate page

Enhance LD_DEBUG to report IFUNC bindings

IRC, freenode, #glibc, 2013-06-20:

<ryanarn> So does anyone have any ideas for a runtime test that can be
  performed to verify that multi-lib/IFUNC support is selecting the proper
  code paths on particular hardware?  Think regression testing, not debug
  testing.
<f11> on the hardware? if it's using some specific instructions, you may be
  able to use perf or similar to count them
<f11> or just script gdb
<ryanarn> f11: I thought of the gdb method.. I suppose if I give the
  testers some scripts.
<ryanarn> actually I like the perf method too.
<ryanarn> f11: thanks
<pasky> ryanarn: can't you simply call the ifunc and check the pointer it
  returns?
<ryanarn> pasky: yes, but I imagine that'll require gdb as well to get the
  start addresses of the libraries whereby I can then determine the address
  of the ifunc selected functions..
<ryanarn> hrm... of the binary itself might be able to do some
  introspection on it's own /proc/pid/maps
<AJaeger> I was just checking whether there'S some LD_DEBUG output for this
  - but couldn't find any.
<AJaeger> Perhaps we need to enhance LD_DEBUG to report ifunc bindings?
<tschwinge> AJaeger: That makes sense to me, yes.
<pasky> ryanarn: well you could just export the symbol of the ifunc as a
  normal function too
<ryanarn> pasky: this is for regression testing of libraries that I don't
  build personally... so doing that would have to be acceptable to do
  upstream.
<ryanarn> but it'd certain be ideal to be able to do something like that
<pasky> ah i see.. hmm, do you at least have debugging symbols?
<ryanarn> pasky: probably in a debug info library.

Support auditing IFUNC resolver functions

See: http://sourceware.org/bugzilla/show_bug.cgi?id=14843

Explore using STT_GNU_IFUNC to support data-dependent function resolvers

The use of STT_GNU_IFUNC is currently limited to a single global decision at application startup when the set of IRELATIVE functions are processed. Even if this were lazy, once processed, the GOT entry referenced by the PLT (at least in the x86_64 implementation) would be set with no easy way to change it. There is an interesting use case where the resolver's decision is data-dependent e.g. signal processing FFT of 4096 points vs. FFT of 8 points. It would be interesting to investigate how we could use the STT_GNU_IFUNC functionality to support redoing the resolver and IRELATIVE relocation based on new information available to the resolver. There is no easy way to support this except with an API directly into the dynamic loader that allows you to re-run the IRELATIVE relocation handling for symbol in question. The alternatives to STT_GNU_IFUNC are: large switch statement with inlined copies, and function pointers; each of which have their own problems.

Locale Voting

Government documents often allow multiple characters to be used for things like thousands separators or decimal points. It would be interesting to try the following:

• Use the glibc locales to create a set of webpages.
• Wire the webpages up to a voting system that allows users to vote on alternatives and correctness of each part of the locale.
• Gather data from voting.
• Incorporate feedback into the locales.

Thus we have crowd-sourced the review of the locales.

Strict and relaxed locales

As soon as you allow crowd-sourcing new locales you need to have a way for governments and schools to select either the strict conforming locale or the more liberal one. We should support some notion of strictness within the locale data and expose a knob to set the locale behaviour e.g. strict or not-strict. In strict mode the locale adheres to government norms, in relaxed mode it adheres to the crowd-sourced data.

Locale archive alignment

Locale archive generation in localedef does page size (4096) alignment as an optimization as explained at https://sourceware.org/ml/libc-alpha/2013-09/msg00764.html - but it is not clear if this is actually beneficial; the effects of this alignment should be analyzed for different choices of the page size used for the writer and the reader.

libm projects

libm itself

• On 32-bit x86, float and double functions should not return values with excess range or precision (which generally means storing return values to memory then loading before return to avoid such excess range and precision). The approaches for fixing this may be different for .c and .S implementations, and there should also be some form of testcase.

• A file k_rem_pio2l.c is automatically built in libm; some systems use the math/ version, with a stub warning, and others use an empty version, but no system actually needs this file. An empty version should be used everywhere, to save the libm space taken up by the stub math/ version on systems using that version.

• pow(+-0, -inf) should ideally not raise the divide-by-zero exception. Current code in glibc may be inconsistent between different implementations; libm-test.inc treats this exception as permitted but optional in this case, following C11, but as per WG14 N1515 proper IEEE semantics indicate the exception should not be raised, so the code and testsuite should be made to follow that.

• Where x86 and x86_64 .S versions of libm functions are similar, it may be useful to share the source files with appropriate conditionals in them.

• It may make sense for x86 and x86_64 expm1l to handle large arguments and setting errno directly, instead of via calling __expl.

• The C implementations of fmod functions appear suboptimal: they could use __builtin_clz operations for subnormals instead of a loop, where the processor has efficient clz support, and the repeated-subtraction loop may be less efficient than approaches using integer mod (where there is hardware support for that) and repeated squaring, where the exponents are widely different. (Before doing much on this, check what processors would actually benefit.)

• There may be problems with the errno setting for overflow and underflow through wrappers (although certain cases are documented not to be expected to set errno). Where the wrappers check the result using __finite, this does not detect underflows (only underflows to 0 matter under the documented rules for setting errno). All the wrappers should be reviewed for any remaining cases of this issue.

• Various routines "optimize" access to constants by storing them in static const variables. Creating an explicit C object like this disables a GCC optimization to store literal constants into .rodata.cstn mergable sections, so that common constants (e.g. pi/2) can be shared between compilation units. (This is only actually a problem for variables in arrays, because of the use of -fmerge-all-constants.)

• Numeric accuracy and the use of -ffp-contract=?. The libm code is currently built using the gcc default behavior of -ffp-contract=fast with the exception of a small number of files that are explicitly called out to be built with -ffp-contract=off. The latter are explicitly called out where it is known that contraction introduces a numerical error. For architectures that provide fused operations, it is possible that some numerical accuracy issues are due to inappropriate contraction. Further, it is also possible that architecture specific code may rely on contraction. Review the C libm files to identify whether they use precision extension techniques that may rely on contracting not occurring; rely on contract; or are indifferent to it.

libm itself (major new features)

The following would be huge projects.

• Support for ISO 24747 special mathematical functions.
• Support for the first part of draft ISO C bindings to IEEE 754-2008 (WG14 N1778 or any more recent version if available) (done apart from functions rounding result to narrower type).
• Integrate libdfp into the glibc repository and update it to N1814 or any more recent version of the proposed updated bindings.

• Support the third part of the IEEE 754-2008 bindings (N1834 or any more recent version), so superseding GCC's libquadmath (make the ldbl-128 functions usable both for long double, and for _Float128 as a type with different representation from long double).

• Support the fourth part of the IEEE 754-2008 bindings (N1836 or any more recent version), with additional functions (glibc already has exp10).

libm testsuite

• Go through the bugs closed as duplicates of bug 14759 for functions not being correctly rounded, and make sure the testcases in question, or other testcases showing ulps at least as big, are in libm-test.inc so the known errors get automatically documented in the manual.

• Review libm-test.inc cases permitting but not requiring exceptions. EXCEPTIONS_OK should no longer be needed.

• The tests in pow_test_data in libm-test.inc and auto-libm-test-in should be sorted into a more logical order; there may be duplicates to remove.

• libm-test.inc should test nexttoward and nextafter more thoroughly, including overflow, underflow and either argument being infinity.

• Test lgamma_r and nan in libm-test.inc.

• Review "XXX" comments in libm-test.inc.

• Replace conditions in libm-test.inc on such macros as TEST_cond_binary32 with testing the relevant features from macros such as MANT_DIG or MAX_EXP instead. (Some of this is being addressed with the move of tests to auto-libm-test-in, but not all.)

• Ideally, errno tests in libm-test.inc should be implied by the exception tests rather than needing to be given explicitly at all, although lots of bugs about not setting errno need to be fixed first. (Again, largely being handled through moves to auto-libm-test-in.)

• libm-test.inc tests should also be run for -lieee, except for tests of errno setting. (There is no need to test the combination of -lieee and inlines.) More generally, run tests for all error-handling modes.

• Run tests with built-in functions enabled to test GCC's handling of those.

• Move more tests to auto-libm-test-in.

• Systematically review coverage in libm-test.inc for the following cases for each function (some of which may result in bugs that need to be filed and fixed before the relevant tests can be added):

  • Large and small inputs of either sign, including subnormals (and expected underflow exceptions for inexact subnormal results).
  • When overflow is possible, inputs (for each floating-point format) just on either side of overflow (inputs that don't quite overflow, and inputs that just overflow).
  • Likewise, for underflow (both values either side of producing subnormal results, and values either side of the rounded result being zero).
  • Also systematically test overflow and underflow cases for directed rounding, which should produce, as appropriate for the rounding direction, either infinity or the largest finite value with the appropriate sign, and either zero or the least subnormal with the appropriate sign.

• It would be useful to have random test generation for all libm functions to search for cases of inaccurate results (more than about 10ulps, or any ulps for fully-defined functions that should always be correctly rounded) or exceptions or errno settings, for all functions (both real and complex) and all floating-point formats (float, double, long double), in all four rounding modes, by comparing with expected results from MPFR and MPC. This would probably be an external project, used to find and report bugs in glibc where not already filed in Bugzilla, rather than a direct part of the glibc testsuite. The random tests would need running on a range of systems, both because of multiarch variants of libm functions and because all three long double formats (ldbl-96, ldbl-128, ldbl-128ibm) should be tested for bugs in this way, as well as architecture-specific versions of various functions. See errors found with mpcheck (but mpcheck needs to be run on more architectures, and there is probably room for multiple random test generation projects in this area).

NPTL

• Some improvements (such as the use of FUTEX_WAIT_BITSET, FUTEX_*REQUEUE_PI) have been added to x86 code only. Need to make analogous changes to the generic code so that architectures that use them can benefit from these improvements. While this is partly done already, there's still more to go.

New functions and features

• Implement aswprintf, vaswprintf, getwdelim, getwline (ISO C TR 24731-2).
• Implement scanf hooks mechanism for use by libraries such as libdfp to extend scanf.

• Implement C11 threads (bug 14092).

• Provide DWARF with proper types for parameters of syscall stubs. Current

Breakpoint 1, open64 () at ../sysdeps/unix/syscall-template.S:82

• should display:

Breakpoint 1, open64 (pathname=0x3dcb21b7d4 "/etc/ld.so.cache", flags=524288) at ../sysdeps/unix/syscall-template.S:82

• Use different libpthread ↔ libthread_db ABI than the "_thread_db_*" .symtab ELF symbols. Distros/people commonly strip all shared libraries and libthread_db no longer works for them.

• A user-level STREAMS implementation should be available if the kernel does not provide the support. This is a much lower priority job now that STREAMS are optional in XPG.
• More conversion modules for iconv(3). Existing modules should be extended to do things like transliteration if this is wanted. For often used conversion a direct conversion function should be available.

• The strptime' function needs to be completed.  This includes among other things that it must get teached about timezones.  The solution envisioned is to extract the timezones from the ADO timezone specifications.  Special care must be given names which are used multiple times.  Here the precedence should (probably) be according to the geograhical distance.  E.g., the timezone EST should be treated as the Eastern Australia Time' instead of the US `Eastern Standard Time' if the current TZ variable is set to, say, Australia/Canberra or if the current locale is en_AU.

Configure based on compiler configuration

How glibc configures itself, regarding ABI choice and CPU optimizations, should be based more on how the compiler ($CC $CFLAGS $CPPFLAGS) generates code, and less on the configured host triplet or configure options for selecting particular variants. See sysdeps/arm/preconfigure.ac for an example of the preferred approach. See https://sourceware.org/ml/libc-alpha/2013-04/msg00357.html and https://sourceware.org/ml/libc-alpha/2013-04/msg00393.html for discussion. Specific points include:

• This would subsume --with-fp / --without-fp.

• --with-cpu would just imply an addition to $CC.

• sysdeps/arm/preconfigure.ac might be made into generic code, where each architecture just supplies a table mapping preprocessor defines to submachine choices.

• Just as GCC configured for x86_64 supports i686 code generation with -m32, so glibc configured for x86_64 with CC="gcc -m32" would automatically set the selected host to i686, and similarly in other 32-bit/64-bit cases.

• sysdeps/powerpc/powerpc32/Makefile would cease to add -mhard-float in certain cases, instead assuming the compiler configuration is correct.

Standards conformance

• Review and update the list in the manual of supported standards and feature test macros for them.
• Where a feature required by a supported standard is deliberately not supported (for example, where an old version of a standard imposed a requirement that was relaxed in a later version because it proved problematic on some systems), this should be explicitly documented in the manual.
• Where a standard documents some feature as optional, it should be explicitly documented which such features glibc supports.
• Develop a way of tagging bugs in Bugzilla that relate to conformance to some standard, and tag existing such bugs. (The std-isoc and std-posix keywords have been added for this purpose.)
• Existing known conformance issues, and lists of such issues, not generally listed in Bugzilla, include the following. Where possible, issues should be moved to properly tagged Bugzilla issues (or listed directly here rather than indirectly) rather than being in such separate lists.

  • The CONFORMANCE file lists some issues.

  • ISO C and POSIX require that functions can be used without including the corresponding header, if the function's type involves only built-in C types and not any type defined in a header. In some cases, glibc headers redirect calls to a differently-named function, conforming to the standard where the default version does not. Redirections in glibc headers should be reviewed to identify such cases. They might be fixed using the redefine_extname pragma in stdc-predef.h, when supported (GCC supports that pragma on all platforms in version 4.5 and later; version 4.8 is needed for implicit inclusion of stdc-predef.h). In the case where the redirection is only for feature-test macros such as _FILE_OFFSET_BITS=64, a separate header could be used as described at https://sourceware.org/ml/libc-alpha/2012-09/msg00133.html.

  • https://sourceware.org/ml/libc-alpha/2013-12/msg00285.html links to some previous discussions of conformance issues. Someone needs to go through those discussions and identify individual issues (or possible issues) that are not fully fixed, listing the individual issues either here or in appropriately tagged bugs in Bugzilla, and tracking which parts have been reviewed.

  • powerpc malloc alignment is bug 6527 but is called out here separately for its complexity. The difficulty in fixing this bug relates to existing Emacs binaries using malloc_set_state. A previous discussion suggests that malloc_set_state only needs to mark memory unfreeable. This issue applies to i386 as well when decimal floating point extensions are considered.

  • If C99/C11 imaginary types were implemented in GCC, updates would be needed to at least <complex.h> and <tgmath.h>.

Architecture-specific

* Update architectures that are out of date or out of sync with other architectures. See PortStatus for a list of issues.

Power

Fixup dl-trampoline.S

Save VRS in fpu dl-trampoline.S

• Need to save non-volatile VRS in:
  • sysdeps/powerpc/powerpc32/dl-trampoline.S
  • sysdeps/powerpc/powerpc64/dl-trampoline.S

Move dl-trampoline.S

• Currently in:
  • sysdeps/powerpc/powerpc32/dl-trampoline.S
  • sysdeps/powerpc/powerpc64/dl-trampoline.S
• Todo: Move to:
  • sysdeps/powerpc/powerpc32/fpu/dl-trampoline.S
  • sysdeps/powerpc/powerpc64/fpu/dl-trampoline.S

Add nofpu version of dl-trampoline.S

• Current versions of powerpc dl-trampoline.S use FP regs and are picked up by soft-float build.
• Currently only a problem when building a profile build.
• Todo: Clone and modify for nofpu which doesn't use FP regs in:
  • sysdeps/powerpc/powerpc32/nofpu/dl-trampoline.S
  • sysdeps/powerpc/powerpc64/nofpu/dl-trampoline.S

Use Cache-Line Size Querying String Routines in ld.so

• When building a toolchain for the Power Architecture it is standard to build with -mcpu=power4 (or later) for the base. This populates lib[64]/ with power4 tuned versions of ld[64].so and libc.so, et al as the 'base' libraries.
  

• Following this, optimized versions of libc.so, libm.so, et al are put into lib[64]/power-foo/ but not an optimized version of ld[64].so.
  

• The 'base' ld[64].so is used always used. It loads the optimized lib[64]/power-foo/ libraries at application runtime.
  

• This can be problematic when 'base' is built with -mcpu=power4 which has a 128-byte cache-line size but ld[64].so is running on power-foo which has a 64-byte cache-line size.
  

• In this case the base ld[64].so using the power4 optimized string routines makes an incorrect assumption of the cache-line size of power-foo.
  

• To solve this the dynamic link loader shouldn't make an assumption of cache-line size in the string routines it uses. The dynamic-linker should always be built using the cache-line-size querying string routines. Then the optimized versions of libc.so can use the hard-coded cache-line size.

• Currently building with a base of -mcpu=power4 will select:
  • sysdeps/powerpc/powerpc32/power4/memcpy.S
  • sysdeps/powerpc/powerpc64/power4/memcpy.S
• This is okay for libc.so but ld[64].so needs to have the file selection hard coded to use:
  • string/memcpy.c

Make Malloc Return Type Alignment Honor ISO C-spec

• This is required by the PowerPC ABIs as well for the Long Double 128, _Decimal128, and Vector Scalar data-types. Unfortunately the impacts are into common code.

• See bug 6527. The changes to generic code are present, but the correct alignment is enabled only for x32, not powerpc32.

  • Rejection Rationale: Ulrich Drepper says this breaks EMACS.
• Suggested approach:
  • Add version wrappers around the old versions of the function.
  • Create new versions of the function which follow the ISO C Spec and psABIs where the sizeof the malloc return type is aligned with the size of the largest supported data-type.
  • Make sure EMACS explicitly uses the old versions.

Improve Time Performance

• unix/time.c calls gettimeofday the linux/time.c uses the time syscall
• gettimeofday will use the vdso
• for vdso platforms the unix/time.c is better then the linux/time.c
• copy sysdeps/unix/sysv/linux/sparc/sparc64/time.c to sysdeps/unix/sysv/linux/powerpc/powerpc64/time.c
• for extra credit create a linux/powerpc/time.c that calls vdso directly.
• vdso availability is based on a kernel feature. The gettimeofday implementations call INLINE_VSYSCALL(gettimeofday). The INLINE_VSYSCALL macro checks for vdso availability. Lacking that is calls the slower syscall.

Improve rand/random Performance

• For 'random' calls of TYPE_0 the sequence:

    if (buf->rand_type == TYPE_0)
      {
        int32_t val = state[0];
        val = ((state[0] * 1103515245) + 12345) & 0x7fffffff;
        state[0] = val;
        *result = val;
      }

  • doesn't need to be protected by a heavy weight lock and unlock when a compare and swap will suffice.
• Todo: In stdlib/random.c:

    __libc_lock_lock (lock);
    (void) __srandom_r (x, &unsafe_state);
    __libc_lock_unlock (lock);

• Add a condition check for TYPE_0:

     if (x->rand_type == TYPE_0)
      {
        /* Compare and Exchange and set '&unsafe_state'  */
      } else {
        __libc_lock_lock (lock);
        (void) __srandom_r (x, &unsafe_state);
        __libc_lock_unlock (lock);
      }

Platform specific implementations that use hardware acceleration when it is faster(AES instruction..)

Optimize Wrappers For Libm

For P5 and P6 inline the isnan, isinf etc tests into the wrapper functions (w_pow.c, w_exp.c, w_log.c, w_sin.c ....). For P7 inline the ftdiv instruction, especially for w_pow as it needs to test 2 operands for isnan(), ifinite(), sign,....

Optimize itoa_word using DFP Instructions for P6 and P7

• Converting into to DPD then DPD to packed then converting to string will be faster than the multiply/divide by 10.

Optimize math functions for P7: __ieee754_exp, ___ieee754_pow, __dubsin

• Verify where we can gain some performance in these functions using P7 instructions.

Thread Priority

• Per ISA 2.06: Section 3.1 (page 671) titled "Program Priority Registers", The 'normal' process priority level has changed from "001 medium" to "100 medium low".

• Reference "Program Priority Registers per ISA 2.06".

• Leveraging this change allows two levels of performance improvement.
  1. Kernel Change - Make priority changes permanent. Without the kernel patch the priority will return to the old normal on a context switch.
  2. GLIBC change - Optimize locking loops to increase priority when lock is taken, decrease when lock is tried but missed, and return priority when lock is released.
     • If there is no accompanying kernel change the GLIBC patch is still beneficial. If a thread is in a critical section and the critical section is long enough that a context switch takes place the critical section is probably too long anyway so the return to the old-normal priority is OK.

Build Wide Character Strings Functions With -O3 Optimization

Memcpy Optimizations for 32-bit and 64-bit Cell

Fix Excessive Implies Files

• Removing excessive Implies files from the powerpc sysdep directories should return the search order to some semblance of hierarchical sanity.

Remove no-fpu Context Routine Save and Restore of fprs

• Currently the context routines reside in powerpc/powerpc[32|64]/ and they contain saving and restoring of fprs and the fpscr.

• This breaks soft-float. This should be fixed so that the fpr and fpscr save and restore are moved into the sysdeps powerpc/powerpc[32|64]/fpu directory.

MIPS

• Review all sysdeps/unix/sysv/linux/wordsize-64 files for cases where n64 (which doesn't use sysdeps/unix/sysv/linux/wordsize-64) needs something fixed.
• n64 should use sysdeps/ieee754/dbl-64/wordsize-64/; n32 should use it except for lround / llround.
• Add localplt baselines or otherwise adapt or skip the localplt tests for MIPS.

• Add CFI information to assembly sources without it - see http://sourceware.org/ml/libc-ports/2013-02/msg00006.html for a list.

i386

• We no longer support i386 and therefore i486 should become the default selection. In order to make i486 the default we will need to merge the i486 sysdep directory down one into the generic i386 directory. Unfortunately the i386 directory will no longer be i386, which is why there is another todo entry to rename from i386 to ix86 or x86/ia32.

• We no longer support i386, but still all of our configuration systems and naming for 32-bit builds is called i386. This should be changed to ix86 or x86. The problem with changing to x86 is that x86-64 and x32 use x86 as a common shared directory. The linux kernel uses x86/ia32 for 32-bit x86 code and we could follow suit to allow kernel developers and other developers familiar with kernel layout to more easily follow our tree layout. During the name transition the i486 implementation should be collapsed out of the i486 directory and moved into the generic ia32 directory, thus we would have i486 default with i586, i686 and i786 options.

Linux Kernel

This section documents issues where there are deficiencies in the kernel/userspace interface.

Improvements to GLibc to better support sandboxing

After a fork in a multithreaded program a number of things are messed up and so only AC-safe (async-signal-safe) functions can be relied upon with certainty. Furthermore, Linux drops capabilities after an execve to another program. To better support sandboxing features, GLibc needs to clarify and possible improve the async-signal-safety of a number of functions.

GLibc needs to document pthread_sigmask, prctl and unshare and note them as AS-safe. They are simple system call wrappers and are most likely AS-safe.

Privilege setting system calls such as setuid, and setgroups are important to sandbox and restrict the privileges of a child process. However, these system calls have to do some complicated setxid synchronization. As such, they can cause deadlocks in programs that use them after a fork in a multithreaded program. This problem has already affected at least one project and has probably affected more (see https://www.redhat.com/archives/libvir-list/2013-November/msg00577.html). This part of having GLibc better support sandboxing is basically another part of the setXid issues mentioned below.

It would be desirable to make functionality like initgroups that read configuration information to reset user state async-signal-safe but as they can potentially call into plugins that can do anything it is probably impossible to reasonably accomplish this and it is sort of out of scope.

setXid issues

POSIX requires that the segXid e.g. setgid functions set the id for the process as a whole. This means that any threads also need their ids changed. At present the kernel provides no way to do this atomically. In glibc this is implemented by iterating over all threads making them call signal handlers to call setXid themselves. This is error prone and failure could cause any number of threads to be left with the old gid. The security implications of this are stagering, but in 2004 it seemed that the kernel was unwilling to accept code to implement this (See https://sourceware.org/ml/libc-hacker/2004-09/msg00068.html).

We need to put together a set of patches to implement setXid in the kernel as an atomic operation to change the id of all threads under a given process.

Synchronizing Headers

Synchronize various kernel UAPI headers and their equivalent libc header so either one can be used and both can be included in any order. See the Synchronizing Headers wiki page.

nscd projects

• Support invalidating more than one database at a time (e.g. nscd -i passwd group hosts services)

• Support invalidating all databases (e.g. nscd -I)

Translations

Write translations for the GNU libc message for the so far unsupported languages. GNU libc is fully internationalized and users can immediately benefit from this. Please visit http://translationproject.org/html/welcome.html and work with the translation project.