[PATCH] Upstreaming a large amount of patches
Christian Seiler <[email protected]> Tue, 22 Mar 2016 21:28:01 +0100
| Newsgroups | gmane.linux.lib.dietlibc |
|---|---|
| Message-ID | <[email protected]> |
Hi,
I've started helping out with the Debian package of dietlibc, because
the current package in unstable is ~ 4 years old and really needs an
update.
I've already uploaded a version to Debian's experimental repository
that is based on a recent CVS snapshot, but one thing I noticed is that
there are a _lot_ of local patches in the Debian package - and the vast
majority of them are not Debian-specific.
To make this as easy as possible for you, I've gone through the patches
in Debian, rebased them on a current CVS snapshot and categorized them.
I've provided a brief explanation for each of the patches as well as
the original authors of them.
Here we go (URLs are directly wget-able):
============================== GENERIC BUGFIXES =======================
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/bugfix-01-dont-flush-stdin-on-fflush-NULL.patch
fflush(NULL) shouldn't flush stdin, since it should only flush
output streams, see man fflush(3):
If the stream argument is NULL, fflush() flushes all open output
streams.
Technically, even with this patch the behavior is still wrong,
because _all_ output streams should be flushed, not just stdout
and stderr. However, that would be quite complicated and I'm not
sure people actually need that, so I'll leave it at that here.
Patch author: Gerrit Pape <[email protected]>
Fixes Debian bug: https://bugs.debian.org/346437
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/bugfix-02-dont-clobber-HOME.patch
Makefile shouldn't clobber the HOME environment variable, as that
may break the build in certain circumstances. The patch renames
HOME in Makefile to DIETHOME (the C code already uses DIETHOME)
to avoid this problem.
Patch author: Ted Percival <[email protected]>
Fixes Debian bug: https://bugs.debian.org/393682
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/bugfix-03-utimes-warning.patch
utimes is only defined in sys/time.h if _BSD_SOURCE is, but
dietlibc doesn't set that define itself, hence utimes() is
not declared when compiling lib/__utime.c. Declare it directly.
Patch author: Thorsten Glaser <[email protected]>
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/bugfix-04-aliasing.patch
Some source files play a bit loose with C's aliasing rules - but
newer compilers are more aggressive in their optimizations when
it comes to aliasing. Hence, compile those specific source files
with -fno-strict-aliasing explicitly to be on the safe side.
Patch author: Thorsten Glaser <[email protected]>
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/bugfix-05-select-testcase.patch
Actually check the return value of select() in the test case.
Patch author: Thorsten Glaser <[email protected]>
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/bugfix-06-lltostr.patch
__lltostr missed some unsigned specifiers for the parameters in
lib/__lltostr.c that are present in include/stdlib.h, causing
build issues. This patch brings the parameters in line with the
stdlib.h header. (And also with _ltostr, which doesn't have this
problem.)
Patch author: Christian Seiler <[email protected]>
Fixes Debian bug: https://bugs.debian.org/748037
============================== PORTING ================================
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-01-ppc_newselect.patch
The select syscall was apparently removed from PPC quite a while
ago, only _newselect is available for at least a decade, so use
that instead.
Patch author: Gerrit Pape <[email protected]>,
Thorsten Glaser <[email protected]>
Fixes Debian bug: https://bugs.debian.org/394928
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-02-unify-umount-handling.patch
Some architectures have __NR_umount taking 1 argument and
__NR_umount2 taking 2. Others have only __NR_umount2. Yet others
have __NR_umount beigng __NR_umount2 with some of those having
also __NR_oldumount.
To simplify this: where both __NR_umount and __NR_umount2 exist,
keep the current behaviour. Otherwise, define two syscall numbers
__NR_umount_with_flags and __NR_umount_without_flags that are
used to simplify the handling of this on other platforms.
Patch author: Simon McVittie <[email protected]>
Fixes Debian bug: https://bugs.debian.org/508397
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-03-add-umount-ia64-wrapper.patch
To properly fix the previous mentioned issue, implement a wrapper
on ia64 for the umount syscall. Should go together with the
previous patch.
Patch author: Simon McVittie <[email protected]>
Fixes Debian bug: https://bugs.debian.org/508397
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-04-sparc-v9-doesnt-imply-64bit.patch
__sparc_v9__ doesn't imply 64bit, it can also be 32bit SPARC with
-mcpu/-march set to v9. To make matters worse, there has been a
lot of confusion about the defined compiler symbols for SPARC. In
In reality the constants defined are the following:
__sparc__ and __arch64__: 64bit SPARC v9 with at least the GNU
compiler
__sparc_v9__: GNU compiler define on both 64bit and 32bit with
the corresponding -mcpu/-march setting
__sparcv9: SUN-only compiler define on 64bit
This patch fixes this and also defines __WORDSIZE_COMPAT32 on
64bit SPARC. (Otherwise utmp is really wrong there.)
Patch author: Ivan Jager <[email protected]>
Fixes Debian bug: https://bugs.debian.org/604717
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-05-arm-FUNC_START_END.patch
Makes sure that all remaining ARM functions use FUNC_START and
FUNC_END (together with arm-features.h) to properly support both
EABI and non-EABI systems.
Patch author: Héctor Orón Martínez <[email protected]>,
Thorsten Glaser <[email protected]>
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-06-ssize_t.patch
Some architectures define size_t as unsigned int instead of
unsigned long, and since int != long (even if they are the same
size), gcc -Wformat will complain if '%zd' is used as a format
string for ssize_t. This is really unfortunate, because it's a
false positive and clutters build logs with needless warnings
that may seem serious.
There is a architecture-portable workaround that works well with
gcc, which this patch implements.
Patch author: Thorsten Glaser <[email protected]>
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/porting-07-ARMv6-VFPU.patch
If you have an ARMv6 CPU (i.e. ARM11 architecture) that has FPU
support, it's already a VFPU (vector floating point unit) and
not an older FPU that was found in e.g. some ARMv5 chips. The
check in __longjmp.S and setjmp.S to see what registers need to
be saved (and how) is hence wrong, because it only checks for
ARMv7 and not ARMv6. This patch fixes that.
Note that this is relevant, because the 1st generation Raspberry
Pi has an ARMv6 chip with hardware floating point. And while most
distributions base their hardware floating point versions on
ARMv7 (including Debian itself), there are distributions for v6
chips (such as Raspbian) that support hardware floating point.
Patch author: Héctor Orón Martínez <[email protected]>
============================== FEATURES ===============================
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/features-01-reproducible-builds.patch
Debian is currently working on making the archive reproducible,
see <https://reproducible-builds.org/> for details. dietlibc has
one issue so far as I can tell, which is that the order of how
the files are added to the library depends on the underlying
filesystem, see <https://reproducible-builds.org/docs/stable-inputs/>.
The attached patch sorts the files during the build process to
make the order deterministic. Basically, $(wildcard ...) is
replaced by $(sort $(wildcard ...)) in the Makefiles.
(You still need a patched toolchain for the build to actually
be reproducible.)
Patch author: Reiner Herrmann <[email protected]>
========================== UNCLEAR STUFF ==============================
* Out of bounds memory access with fast string functions without
WANT_SMALL_STRING_ROUTINES
The following string functions have variants that read up to 7
bytes beyond possible buffer sizes. Specifically, this affects:
- arm/strcpy.S
- arm/strlen.S
- lib/strcmp.c
- lib/strcpy.c
- lib/strlen.c
Not affected are:
- lib/strcat.c
- lib/strncat.c
- lib/strrchr.c
- lib/strchr.c
manual loop unrolling
- lib/memcpy.c
only uses word-size access as long as at least a word is
left to be copied
This out-of-bounds access is problematic because some memory
allocators enforce buffer boundaries explicitly; and it also
generates tons of false positives with valgrind and similar
tools.
The package in Debian has had a patch for the last 5 years that
removes the string function variants that perform out of bounds
access. I've looked at the patch and it just removes stuff
between the #ifndef WANT_SMALL_STRING_ROUTINES and the #endif in
those cases, but I feel really uncomfortable carrying such a
patch going forward (I have the OpenSSL situation from a couple
of years ago in the back of my mind), so I'd rather have this
upstream. Of course, you might want to keep the faster function
variants regardless, but may I at least suggest adding another
define WANT_FAST_OOB_STRING_FUNCTIONS to enable them. If you are
agreeable to this, I can write a patch that does just that.
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/unclear-A01-SSP-no-stack-protector.patch
Ubuntu's gcc passes -fstack-protector by default, so if dietlibc
is compiled without WANT_SSP, it should explicitly pass
-fno-stack-protector to the compiler.
Patch author: Thorsten Glaser <[email protected]>
This has been carried in Debian because Debian has historically
disabled SSP due to toolchain issues; this will not be the case
any more for future versions (because recent toolchains aren't
buggy in this regard anymore and we want SSP to make attacks more
difficult), so it's unclear what should happen with this patch
now, especially since it just presupposes that the compiler
understands the flag -fno-stack-protector... OTOH, people
compiling dietlibc on Ubuntu themselves from upstream will run
into trouble without this patch if they disable WANT_SSP...
Maybe this should be mentioned in the documentation instead? Or
at least a comment in dietfeatures.h next to WANT_SSP?
https://gist.githubusercontent.com/chris-se/e35381c75583a4c4bce2/raw/8bf327a048f396220c48fb4ffbd504d12b042007/unclear-A02-native-x32.patch
Debian has a native x32 port (currently still unofficial), where
all binaries of the system can be x32. In that case, it kind of
makes sense to provide x32 support not only as an "add-on" to
x86_64, but also as its own architecture. Unfortunately, there is
no way to distinguish x86_64 from x32 based on the kernel (that
is identical; uname -m returns x86_64 in both cases), because
only the userland is different.
However, with the patch I provided here one can specify
make MYARCH=x32
in order to tell the build system that a full x32 build is
wanted. And it also has the diet binary assume x32 by default if
if the diet binary was compiled natively.
So while it doesn't help to support native x32 automatically,
hence I moved this patch into the "unclear" category, the
maintenance burden is basically zero, so unless you have a better
idea how to support this, I'd be grateful if you could apply the
patch.
Patch author: Christian Seiler <[email protected]>
The full list can also be found here (can also be git clone'd):
https://gist.github.com/chris-se/e35381c75583a4c4bce2
That's it for now. I'm still working on some other things, but this
email should cover most of the current diff in Debian.
Regards,
Christian