|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|= Todo =
== Support initialization of non-POD thread-local objects ==
|= Machine-independent projects =|
|Line 5:||Line 3:|
|We need to coordinate glibc support.||These projects are machine independent. Given that they apply to all machines we should be thorough with our testing.|
|Line 7:||Line 5:|
|== Support auditing IFUNC resolver functions ==
== 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.
== Documentation ==
* The README file in git needs some cleanup to update the lists of supported systems in libc and ports
* move the FAQ file from git to the wiki. The FAQ is outdated in many aspects, so it needs removal of old entries and changes to existing ones.
* move the PROJECTS file from git to wiki - and remove obsolete entries.
== 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.
== Reviewing ==
* Review the sysdeps code for hppa and alpha: do general comparison of sysdeps files against libc versions to find cases where updates were missed over the past several years. (That would probably take a few hours, based on Joseph's experience doing it with m68k some years ago)
| * [[Development_Todo/Master#BZ27557|Support initialization of non-POD thread-local objects.]]
* [[Development_Todo/Master#BZ14843|Support auditing IFUNC resolver functions.]]
* [[Development_Todo/Master#DataResolvers|Explore using STT_GNU_IFUNC to support data-dependent function resolvers.]]
* [[Development_Todo/Master#LocaleVoting|Locale voting.]]
* [[Development_Todo/Master#RelaxedLocales|Explore strict and relaxed locales.]]
These projects are machine independent. Given that they apply to all machines we should be thorough with our testing.