I've noticed that sync_file_range is a stub on ppc/ppc64.
The kernel on these arches provides sync_file_range2 syscall with swapped
parameters.
The following completely untested patch ought to fix this.
This is another bug in computing the fastmap. It was reported by a user
of sed because it usually does not happen with !_LIBC. However, it is
there in that case too.
The bug is that whenever we have a range at the beginning of the regex,
the regex must be tested on any possible multibyte character. The reason
why _LIBC masks it, is that in general there is a collation symbol for
each possible multibyte-character lead byte, so all the lead bytes are
in general already part of the fastmap.
The tests use cyrillic characters as an example. With _LIBC, they pass
without the patch too, but you can make them fail by removing collation
symbols handling.
With big DNS answers like the one you get for goodtimesdot.com you can
get a truncated address list if IPv6 mapping is enabled. Instead tell
the caller to resize the buffer.
Due to alignment of 64bit parameters there is a dummy second argument.
But other than that the syscall arguments are directly mapped to the
function arguments.
I've just committed STT_GNU_IFUNC ppc/ppc64 support into prelink,
and this patch is needed on the glibc side. Without it ld.so segfaults,
as in dl-conflict.c sym_map is always NULL. While dl-machine.h could use
RESOLVE_CONFLICT_FIND_MAP macro to compute it, it doesn't make sense,
because with prelink we know it is already properly relocated (all relative
relocations are applied by prelink).
As reported in http://bugzilla.redhat.com/533063 , preadv/pwritev prototypes
are wrong on 32-bit arches with -D_FILE_OFFSET_BITS=64 and as I've just
found, fallocate is wrong too.
The problem is that only off_t is remapped to the 64-bit type transparently,
__off_t is not.
