In case of power failure followed by filesystem issues locale-archive
can end-up containing all zeros. In that case all calls to setlocale()
generate a SIGFPE. This renders a system with a default non-C locale
unbootable.
Avoid this by ignoring the locale instead of generating a SIGFPE.
Joseph pointed out in the bug report (and in an earlier thread) that
systemtap probes cause build time warnings like the following:
../sysdeps/ieee754/dbl-64/e_atan2.c:602:4: warning: the address of
'p' will always evaluate as 'true' [-Waddress]
due to the fact that we're now passing non-weak variables to
LIBC_PROBE in the libm probes. This happens only on configurations
that do not enable systemtap. The macro definition of LIBC_PROBE in
this case only acts as a sanity checker to ensure that the number
parameters passed to LIBC_PROBE is equal to the argument count
parameter passed before it. This can be done in a much simpler manner
by just adding a macro definition for each number of arguments. I am
assuming here that we don't really want to bother with supporting
LIBC_PROBE with an indeterminate number of arguments and if there is a
need for a probe to have more data than what is currently supported (4
arguments), one could simply add an additional macro here.
Only gaih_inet() and gaih_inet_serv() use a special bit flag denoted
by the GAIH_OKIFUNSPEC macro. Only the return value of
gaih_inet_serv() is actively checked for the bit flag which is
redundant because it just copies the nonzero property of the value
otherwise returned. The return value of gaih_inet() is only checked
for being zero and then the bit flag is filtered out. As the bit flag
is set only for otherwise nonzero return values, it doesn't affect the
zero comparison. GAIH_EAI just an alias to ~GAIH_OKIFUNSPEC.
AF_INET lookup in hosts file uses _nss_files_gethostbyname2_r, which
is not capable of returning a canonical name if it has found one.
This change adds _nss_files_gethostbyname3_r, which wraps around
_nss_files_gethostbyname2_r and then returns result.h_name as the
canonical name.
Fix the RLIM64_INFINITY constant for O32 and N32 ABIs to match the
kernel one. Change the getrlimit64/setrlimit64 into old compat symbols,
and provide the Linux generic getrlimit64/setrlimit64 functions as
GLIBC_2_19 version.
RLIM64_INFINITY was supposed to be a glibc convention rather than
anything seen by the kernel, but it ended being passed to the kernel
through the prlimit64 syscall. On O32 and N32 ABIs, we therefore
end-up with different values on the userland and kernel side:
* On the kernel side, the value is defined for all architectures as
include/uapi/linux/resource.h:
#define RLIM64_INFINITY (~0ULL)
* On the GNU libc side, the value is defined in
ports/sysdeps/unix/sysv/linux/mips/bits/resource.h:
For the O32 and N32 ABI:
# define RLIM64_INFINITY 0x7fffffffffffffffULL
and for the N64 ABI:
# define RLIM64_INFINITY 0xffffffffffffffffUL
This was not a problem until the prlimit64 syscall was wired in the
2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement
getrlimit64 and setrlimit64, pam_limits.so is setting the limits to
a very big value instead of infinity. As a normal user process can
later only decrease the value and not increase it, it will later get
and EPERM error when trying to set the value to infinity with setrlimit.
The GLIBC has this constant for more than 7 years, and as it is defined
in a header file, it means a lot of binaries are in the wild. This patch
fixes that by adding a wrapper to fix the value passed to or received
from the kernel, before or after calling the prlimit64 syscall.
Add support for handling the R_AARCH64_IRELATIVE relocation and
STT_GNU_IFUNC symbols to the aarch64 port.
ports/ChangeLog.aarch64:
2013-11-26 Will Newton <will.newton@linaro.org>
* sysdeps/aarch64/dl-irel.h: Include ldsodefs.h.
(ELF_MACHINE_IRELA): Define. (elf_ifunc_invoke): Pass
hwcap to ifunc resolver function. (elf_irela): New function.
* sysdeps/aarch64/dl-machine.h: Include dl-irel.h.
(elf_machine_rela) Handle STT_GNU_IFUNC symbols and
R_AARCH64_IRELATIVE relocations. (elf_machine_lazy_rel):
Handle R_AARCH64_IRELATIVE relocations.
The event code is PTRACE_EVENT_SECCOMP, not PTRAVE_EVENT_SECCOMP.
This patch fixes the V->C typo. There are no ABI issues since the
number remains the same for the code. Code using the old wrong
name will need to be updated.
This patch helps some math functions performance by adding the libc_fexxx
variant of inline functions to handle both FPU round and exception set/restore
and by using them on the libc_fexxx_ctx functions. It is based on already coded
fexxx family functions for PPC with fpu.
Here is the summary of performance improvements due this patch (measured on a
POWER7 machine):
Before:
cos(): ITERS:9.5895e+07: TOTAL:5116.03Mcy, MAX:77.6cy, MIN:49.792cy, 18744 calls/Mcy
exp(): ITERS:2.827e+07: TOTAL:5187.15Mcy, MAX:494.018cy, MIN:38.422cy, 5450.01 calls/Mcy
pow(): ITERS:6.1705e+07: TOTAL:5144.26Mcy, MAX:171.95cy, MIN:29.935cy, 11994.9 calls/Mcy
sin(): ITERS:8.6898e+07: TOTAL:5117.06Mcy, MAX:83.841cy, MIN:46.582cy, 16982 calls/Mcy
tan(): ITERS:2.9473e+07: TOTAL:5115.39Mcy, MAX:191.017cy, MIN:172.352cy, 5761.63 calls/Mcy
After:
cos(): ITERS:2.05265e+08: TOTAL:5111.37Mcy, MAX:78.754cy, MIN:24.196cy, 40158.5 calls/Mcy
exp(): ITERS:3.341e+07: TOTAL:5170.84Mcy, MAX:476.317cy, MIN:15.574cy, 6461.23 calls/Mcy
pow(): ITERS:7.6153e+07: TOTAL:5129.1Mcy, MAX:147.5cy, MIN:30.916cy, 14847.2 calls/Mcy
sin(): ITERS:1.58816e+08: TOTAL:5115.11Mcy, MAX:1490.39cy, MIN:22.341cy, 31048.4 calls/Mcy
tan(): ITERS:3.4964e+07: TOTAL:5114.18Mcy, MAX:177.422cy, MIN:146.115cy, 6836.68 calls/Mcy
