| Age | Commit message (Collapse) | Author |
|---|
|
The arguments of the LIBC_SLIBDIR_RTLDDIR macro are used both in unquoted
and single quoted context, so that neither shell nor makefile variable
references work. Consistently put them in single quotes so that they can
refer to makefile variables.
|
|
The sole failure for ColdFire in the compilation part of the glibc
testsuite is the localplt test. This patch adds a localplt baseline
for ColdFire to eliminate that failure. The difference from the
existing m68k baseline is that no PLT entry for _Unwind_Find_FDE is
expected, because ColdFire does not set
libc_cv_gcc_unwind_find_fde=yes.
Tested with build-many-glibcs.py.
* sysdeps/unix/sysv/linux/m68k/localplt.data: Move to ....
* sysdeps/unix/sysv/linux/m68k/m680x0/localplt.data: ... here.
* sysdeps/unix/sysv/linux/m68k/coldfire/localplt.data: New file.
|
|
As with some other soft-float configurations, no-FPU ColdFire needs
various fenv.h functions and glibc-internal macros overridden in
math_private.h to avoid references to undefined FE_* macros when
building glibc. This patch adds a suitable math_private.h, based on
the MicroBlaze one (Nios II and Tile also have similar files).
There's a case for having such a file in sysdeps/ieee754/soft-fp so
this logic is applied more generally to configurations without
exceptions and rounding modes, even when the relevant macros are
defined in fenv.h - the only case where that might be inappropriate is
ARM soft-float (where the fenv.h functions might or might not work at
runtime, depending on whether the processor used at runtime supports
VFP). There's also a case that soft-float configurations (on
processors with both hard-float and soft-float) should more
consistently avoid defining FE_* macros in bits/fenv.h when not
actually supported. But both of those are separate potential
cleanups.
This allows the no-FPU ColdFire build to get further (another fix is
needed to allow the build to complete).
* sysdeps/m68k/coldfire/nofpu/math_private.h: New file. Based on
MicroBlaze file.
|
|
Continuing the fixes for ColdFire glibc build with
build-many-glibcs.py, given a GCC patch for the libgcc build failure,
this patch adds jmp_buf-macros.h for no-FPU ColdFire. This allows the
no-FPU build to progress further than without the patch (although
other fixes are still needed for the build to complete).
* sysdeps/unix/sysv/linux/m68k/coldfire/jmp_buf-macros.h: Move to
....
* sysdeps/unix/sysv/linux/m68k/coldfire/fpu/jmp_buf-macros.h:
... here.
* sysdeps/unix/sysv/linux/m68k/coldfire/nofpu/jmp_buf-macros.h:
New file.
|
|
This patch adds a jmp_buf-macros.h for ColdFire. In conjunction with
a GCC patch to fix the libgcc build failure for ColdFire
<https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02064.html> this
suffices to restore the build (tested with build-many-glibcs.py). A
further patch will be needed for soft-float ColdFire (while the
function-calling ABI is the same for hard-float and soft-float
ColdFire, it turns out the glibc ABI is not - so another ColdFire
variant will be needed in build-many-glibcs.py), but I'll deal with
that separately.
Tested with build-many-glibcs.py (m68k-linux-gnu and
m68k-linux-gnu-coldfire). (There's a localplt test failure for
coldfire; that's the only failure in the compilation part of the
testsuite.)
* sysdeps/unix/sysv/linux/m68k/jmp_buf-macros.h: Move to ....
* sysdeps/unix/sysv/linux/m68k/m680x0/jmp_buf-macros.h: ... here.
* sysdeps/unix/sysv/linux/m68k/coldfire/jmp_buf-macros.h: New
file.
|
|
The uc_mcontext.__reserved member of ucontext_t is a user visible API,
that should not be changed, because this is the only way to access cpu
states of various extensions of linux asm/sigcontext.h, it does not
violate namespace rules either, so revert this part of the commit
commit 4fa9b3bfe6759c82beb4b043a54a3598ca467289
Commit: Joseph Myers <joseph@codesourcery.com>
Fix mcontext_t sigcontext namespace (bug 21457).
(In principle the user can type cast &uc_mcontext to struct sigcontext*
to use the linux sigcontext fields, but that's not the existing practice
since mcontext_t used to be a typedef of struct sigcontext.)
[BZ #22742]
* sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h (__glibc_reserved1):
Rename to __reserved and add comment.
* sysdeps/unix/sysv/linux/aarch64/ucontext_i.sym (__glibc_reserved1):
Rename to __reserved.
|
|
The tunables framework needs to execute syscall early in process
initialization, before the TCB is available for consumption. This
behavior conflicts with powerpc{|64|64le}'s lock elision code, that
checks the TCB before trying to abort transactions immediately before
executing a syscall.
This patch adds a powerpc-specific implementation of __access_noerrno
that does not abort transactions before the executing syscall.
Tested on powerpc{|64|64le}.
[BZ #22685]
* sysdeps/powerpc/powerpc32/sysdep.h (ABORT_TRANSACTION_IMPL): Renamed
from ABORT_TRANSACTION.
(ABORT_TRANSACTION): Redirect to ABORT_TRANSACTION_IMPL.
* sysdeps/powerpc/powerpc64/sysdep.h (ABORT_TRANSACTION,
ABORT_TRANSACTION_IMPL): Likewise.
* sysdeps/unix/sysv/linux/powerpc/not-errno.h: New file. Reuse
Linux code, but remove the code that aborts transactions.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
|
|
* sysdeps/generic/netinet/if_ether.h: Include <stdint.h>.
|
|
The only architecture in glibc that uses the generic debug/backtrace.c
is hppa. The debug/tst-backtrace* tests fail for hppa, so in fact the
generic debug/backtrace.c is not functional anywhere. Instead, the
x86_64 version is a reasonably generic version that uses
_Unwind_Backtrace from libgcc to backtrace using unwind info, and is
used by several architectures. This patch adds hppa to the
architectures using it (leaving open the possibility of a subsequent
cleanup for 2.28 of moving the x86_64 version to debug/backtrace.c,
and removing all the frame.h files that are now unused).
Reported by Adhemerval in
<https://sourceware.org/ml/libc-alpha/2018-01/msg00564.html> that this
does fix the backtrace test failures for hppa.
[BZ #22719]
* sysdeps/hppa/backtrace.c: New file.
|
|
_dl_runtime_profile calls _dl_call_pltexit, passing a pointer to
La_x86_64_retval which is allocated on stack. The lrv_vector0
field in La_x86_64_retval must be aligned to size of vector register.
When allocating stack space for La_x86_64_retval, we need to make sure
that the address of La_x86_64_retval + RV_VECTOR0_OFFSET is aligned to
VEC_SIZE. This patch checks the alignment of the lrv_vector0 field
and pads the stack space if needed.
Tested with x32 and x86-64 on SSE4, AVX and AVX512 machines. It fixed
FAIL: elf/tst-audit10
FAIL: elf/tst-audit4
FAIL: elf/tst-audit5
FAIL: elf/tst-audit6
FAIL: elf/tst-audit7
on x32 AVX512 machine.
[BZ #22715]
* sysdeps/x86_64/dl-trampoline.h (_dl_runtime_profile): Properly
align La_x86_64_retval to VEC_SIZE.
|
|
The x86_64 backtrace implementation is used as a generic
implementation (unwinding via unwind info and _Unwind_Backtrace) by
various other architectures. This patch makes it more generic by
making it use LIBGCC_S_SO from gnu/lib-names.h instead of hardcoding
the libgcc_s.so.1 name, so that it can also be used on hppa which uses
libgcc_s.so.4.
Tested for x86_64.
* sysdeps/x86_64/backtrace.c: Include <gnu/lib-names.h>.
(init): Use LIBGCC_S_SO not hardcoded "libgcc_s.so.1".
|
|
Define new HWCAP bits and add their name to dl-procinfo.c following
the linux definitions. Synchronizing with v4.15-rc8 version of linux,
these are not expected to change before the 4.15 release.
* sysdeps/unix/sysv/linux/aarch64/bits/hwcap.h (HWCAP_SHA3): Define.
(HWCAP_SM3, HWCAP_SM4, HWCAP_ASIMDDP, HWCAP_SHA512, HWCAP_SVE): Define.
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.c
(_dl_aarch64_cap_flags): Update.
(_DL_HWCAP_COUNT): Update.
|
|
Remove unused _DL_HWCAP_LAST definition and move _DL_HWCAP_COUNT
where it is needed (dl-procinfo.h always includes dl-procinfo.c).
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h
(_DL_HWCAP_LAST): Remove.
(_DL_HWCAP_COUNT): Move to ...
* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.c
(_DL_HWCAP_COUNT): ... here.
|
|
This issue is similar to BZ #19235, where spurious exceptions are
created from adding 0.5 then converting to an integer.
The solution is based on Joseph's fix for BZ #19235.
[BZ #22697]
* sysdeps/powerpc/powerpc32/power4/fpu/s_llround.S (__llround):
Do not add 0.5 to integer or out-of-range arguments.
|
|
In the static pie enabled libc, crt1.o uses the same position independent
code as rcrt1.o and crt1.o is used instead of Scrt1.o when -no-pie
executables are linked. When main is not defined in the executable, but
in a shared library crt1.o is currently broken, it assumes main is local.
(glibc has a test for this but i missed it in my previous testing.)
To make both rcrt1.o and crt1.o happy with the same code, a wrapper is
introduced around main: with this crt1.o works with extern main symbol
while rcrt1.o does not depend on GOT relocations. (The change only
affects static pie enabled libc. Further simplification of start.S is
possible in the future by using the same approach for Scrt1.o too.)
* aarch64/start.S (_start): Use __wrap_main.
(__wrap_main): New local symbol.
|
|
Currently getcwd(3) can succeed without returning an absolute path
because the underlying getcwd syscall, starting with linux commit
v2.6.36-rc1~96^2~2, may succeed without returning an absolute path.
This is a conformance issue because "The getcwd() function shall
place an absolute pathname of the current working directory
in the array pointed to by buf, and return buf".
This is also a security issue because a non-absolute path returned
by getcwd(3) causes a buffer underflow in realpath(3).
Fix this by checking the path returned by getcwd syscall and falling
back to generic_getcwd if the path is not absolute, effectively making
getcwd(3) fail with ENOENT. The error code is chosen for consistency
with the case when the current directory is unlinked.
[BZ #22679]
CVE-2018-1000001
* sysdeps/unix/sysv/linux/getcwd.c (__getcwd): Fall back to
generic_getcwd if the path returned by getcwd syscall is not absolute.
* io/tst-getcwd-abspath.c: New test.
* io/Makefile (tests): Add tst-getcwd-abspath.
|
|
My fix for bug 22702 introduced linknamespace test failures on
s390x-linux-gnu and s390-linux-gnu because it made remainder call
__feholdexcept, and the s390 __feholdexcept calls fegetenv, and
remainder is in Unix98 and XPG4.2 but fegetenv isn't. This patch
makes __feholdexcept call __fegetenv instead to avoid that namespace
issue.
Tested (compilation) with build-many-glibcs.py for s390x-linux-gnu,
where it resolves the test failures.
* sysdeps/s390/fpu/feholdexcpt.c (__feholdexcept): Call __fegetenv
instead of fegetenv.
|
|
For soft-float powerpc, the math/test-nearbyint-except-2 test fails
because nearbyintl traps when traps on "inexact" are enabled on entry
(and an "inexact" exception is generated internally, though cleared
for the final return).
The problem is the default implementation of
libc_feholdsetround_noex_ctx, which does not disable exception traps.
There is some ambiguity about whether the *noex* interfaces are
required to do so or only permitted to do so. But given that we
support fe* interfaces to enable and disable traps (on architectures
with that functionality), functions that must not raise an exception
(must not leave the flag set on exit if not set on entry) should also
not trap on it when traps on that exception are enabled. So it is
appropriate to define these interfaces to have the feholdexcept effect
of disabling exception traps; this patch updates the default
implementation and comments accordingly.
At least some architecture versions already disable traps; there are
few uses of the *noex* interfaces at all, and while it's possible
there are bugs on any architecture versions failing to disable traps
that appear in the exp2 and remainder implementations, there are
currently no tests, other than this one for nearbyintl (where only the
ldbl-128ibm implementation uses SET_RESTORE_ROUND_NOEX), that would
fail as a result of such a bug. (Hard-float powerpc does disable
traps here, hence the nearbyintl failure not appearing there.)
Tested for powerpc (soft-float). This brings that configuration to
clean math/ test results, provided you build with GCC 8 to get the fix
for GCC bug 64811.
[BZ #22702]
* sysdeps/generic/math_private.h (libc_feresetround_noex): Update
comment to say exceptions are discarded.
(libc_feholdsetround_noex_ctx): Use __feholdexcept instead of
__fegetenv.
(SET_RESTORE_ROUND_NOEX): Update comment to say non-stop mode must
be enabled.
|
|
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
|
The ldbl-128ibm implementation of log1pl does ordered comparisons on a
negative qNaN argument, so resulting in spurious "invalid" exceptions
(for soft-float powerpc; hard-float only avoids this because of GCC
bug 58684 meaning ordered comparison instructions never get
generated). This patch fixes this by arranging for the test for NaN
or infinity arguments to handle negative arguments as well.
Tested for powerpc (soft float).
[BZ #22693]
* sysdeps/ieee754/ldbl-128ibm/s_log1pl.c (__log1pl): Handle
negative arguments in test for NaN or infinity argument.
|
|
Disabling lazy binding reduces stack usage during unwinding.
Note that RTLD_NOW only makes a difference if libgcc.so has not
already been loaded, so this is only a partial fix.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
* hurd/hurd/fd.h: Include <fcntl.h>
(__hurd_at_flags): New function.
* hurd/lookup-at.c (__file_name_lookup_at): Replace flag computation
with call to __hurd_at_flags.
* include/unistd.h (__faccessat, __faccessat_noerrno): Add declaration.
* sysdeps/mach/hurd/access.c (access_common): Move implementation to
__faccessat
(hurd_fail_seterrno, hurd_fail_noerrno): Move to sysdeps/mach/hurd/faccessat.c.
(__access_noerrno): Use __faccessat_common instead of access_common.
(__access): Likewise.
* sysdeps/mach/hurd/euidaccess.c (__euidaccess): Replace implementation
with a call to __faccessat.
* sysdeps/mach/hurd/faccessat.c (faccessat): Rename into...
(__faccessat_common): ... this. Move implementation of __access into it when
AT_FLAGS does not contain AT_EACCESS. Make it call __hurd_at_flags, add
reauthenticate_cwdir_at helper to implement AT mechanism.
(__faccessat_noerrno): New function, just calls __faccessat_common.
(__faccessat): New function, just calls __faccessat_common.
(faccessat): Define weak alias.
|
|
For soft-float powerpc, fmaxmagl and fminmagl generate spurious
"invalid" exceptions for quiet NaN arguments. This is another case of
the problems with fabsl inline expansion via comparisons, and so is
fixed by building those functions with -fno-builtin-fabsl.
Tested for powerpc (soft-float).
[BZ #22691]
* sysdeps/powerpc/nofpu/Makefile [$(subdir) = math]
(CFLAGS-s_fmaxmagl.c): New variable.
[$(subdir) = math] (CFLAGS-s_fminmagl.c: Likewise.
|
|
The ldbl-128ibm implementations of lrintl and lroundl are missing
"invalid" exceptions for certain overflow cases when compiled with GCC
8. The cause of this is after-the-fact integer overflow checks that
fail when the compiler optimizes on the basis of integer overflow
being undefined; GCC 8 must be able to detect new cases of
undefinedness here.
Failure: lrint (-0x80000001p0): Exception "Invalid operation" not set
Failure: lrint_downward (-0x80000001p0): Exception "Invalid operation" not set
Failure: lrint_towardzero (-0x80000001p0): Exception "Invalid operation" not set
Failure: lrint_upward (-0x80000001p0): Exception "Invalid operation" not set
Failure: lround (-0x80000001p0): Exception "Invalid operation" not set
Failure: lround_downward (-0x80000001p0): Exception "Invalid operation" not set
Failure: lround_towardzero (-0x80000001p0): Exception "Invalid operation" not set
Failure: lround_upward (-0x80000001p0): Exception "Invalid operation" not set
(Tested that these failures occur before the patch for powerpc
soft-float, but the issue applies in principle for hard-float as well,
whether or not the particular optimizations in fact occur there at
present.)
This patch fixes the bug by ensuring the additions / subtractions in
question cast arguments to unsigned long int, or use 1UL as a constant
argument, so that the arithmetic occurs in an unsigned type with the
result then converted back to a signed type.
Tested for powerpc (soft-float).
[BZ #22690]
* sysdeps/ieee754/ldbl-128ibm/s_lrintl.c (__lrintl): Use unsigned
long int for arguments of possibly overflowing addition or
subtraction.
* sysdeps/ieee754/ldbl-128ibm/s_lroundl.c (__lroundl): Likewise.
|
|
For soft-float powerpc, the remainderl function produces zero results
with the wrong sign for various inputs. This is another instance of
the problem with incorrect built-in fabsl expansion, so is fixed by
this patch using -fno-builtin-fabsl for this function.
Tested for powerpc (soft-float).
[BZ #22688]
* sysdeps/powerpc/nofpu/Makefile [$(subdir) = math]
(CFLAGS-e_remainderl.c): New variable.
|
|
(bug 22687).
For soft-float powerpc, various _Complex long double functions
generate spurious "invalid" exceptions, even with a compiler with GCC
bug 64811 fixed.
The problem is GCC's built-in fabsl expansion. Various files are
already built with -fno-builtin-fabsl because in this case (IBM long
double, for soft-float or e500v1) a fallback fabsl expansion based on
comparisons is used, which can produce the wrong sign of a zero
result. Those comparisons can also produce spurious exceptions for
NaN arguments. Furthermore, __builtin_fpclassify implemently uses
__builtin_fabsl, and is unaffected by -fno-builtin-fabsl, and the
fpclassify macro uses __builtin_fpclassify in the absence of
-fsignaling-nans. Thus, this patch arranges for the problem files
using fpclassify to be built with -fsignaling-nans in this case, to
avoid spurious exceptions from fpclassify.
Tested for powerpc (soft-float).
[BZ #22687]
* sysdeps/powerpc/nofpu/Makefile (CFLAGS-s_cacosl.c): New
variable.
(CFLAGS-s_cacoshl.c): Likewise.
(CFLAGS-s_casinhl.c): Likewise.
(CFLAGS-s_catanl.c): Likewise.
(CFLAGS-s_catanhl.c): Likewise.
(CFLAGS-s_cexpl.c): Likewise.
(CFLAGS-s_ccoshl.c): Add -fsignaling-nans.
(CFLAGS-s_csinhl.c): Likewise.
(CFLAGS-s_clogl.c): Likewise.
(CFLAGS-s_clog10l.c): Likewise.
(CFLAGS-s_csinl.c): Likewise.
(CFLAGS-s_csqrtl.c): Likewise.
|
|
From: Emilio Pozuelo Monfort <pochu27@gmail.com>
From: Svante Signell <svante.signell@gmail.com>
Pass the file paths of executable to the exec server, both relative and
absolute, which exec needs to properly execute and avertise #!-scripts.
Previously, the exec server tried to guess the name from argv[0] but argv[0]
only contains the executable name by convention.
* hurd/hurdexec.c (_hurd_exec): Deprecate function.
(_hurd_exec_paths): New function.
* hurd/hurd.h (_hurd_exec): Deprecate function.
(_hurd_exec_paths): Declare function.
* hurd/Versions: Export _hurd_exec_paths.
* sysdeps/mach/hurd/execve.c: Include <stdlib.h> and <stdio.h>
(__execve): Use __getcwd to build absolute path, and use
_hurd_exec_paths instead of _hurd_exec.
* sysdeps/mach/hurd/spawni.c: Likewise.
* sysdeps/mach/hurd/fexecve.c: Use _hurd_exec_paths instead of
_hurd_exec.
|
|
* sysdeps/unix/sysv/linux/tst-ttyname.c (do_in_chroot_1): Skip the
test instead of failing in case of ENOENT returned by posix_openpt.
|
|
Since the x86-64 assembly version of sincosf is higly optimized with
vector instructions, there isn't much room for improvement. However
s_sincosf.c written in C with vector math and intrinsics can be
optimized by GCC with FMA.
On Skylake, bench-sincosf reports performance improvement:
Assembly FMA improvement
max 104.042 101.008 3%
min 9.426 8.586 10%
mean 20.6209 18.2238 13%
* sysdeps/x86_64/fpu/multiarch/Makefile (libm-sysdep_routines):
Add s_sincosf-sse2 and s_sincosf-fma.
(CFLAGS-s_sincosf-fma.c): New.
* sysdeps/x86_64/fpu/multiarch/s_sincosf-fma.c: New file.
* sysdeps/x86_64/fpu/multiarch/s_sincosf-sse2.S: Likewise.
* sysdeps/x86_64/fpu/multiarch/s_sincosf.c: Likewise.
* sysdeps/x86_64/fpu/s_sincosf.S: Don't add alias if
__sincosf is defined.
|
|
Commit 24731685 ("prlimit: Translate old_rlimit from RLIM64_INFINITY to
RLIM_INFINITY") broken the getrlimit64 for 32-bit configurations which
do no need the 2GiB limited compat getrlimit (default version >= 2.2).
This patch fixes that by restoring the weak alias in that case.
Changelog:
* sysdeps/unix/sysv/linux/getrlimit64 (getrlimit64)
[!__RLIM_T_MATCHES_RLIM64_T]
[!SHLIB_COMPAT (libc, GLIBC_2_1, GLIBC_2_2)]: Define as weak alias of
__getrlimit64. Add libc_hidden_weak.
|
|
This follows c45d78aac ('posix: Fix generic p{read,write}v buffer allocation
(BZ#22457)'), which made pwritev to use __mmap instead of __posix_memalign,
but didn't pass PROT_READ to it, while the pwrite() call does need to
read the data we have just copied over.
* sysdeps/posix/pwritev_common.c: Add PROT_READ to __mmap prot.
|
|
The RISC-V Linux port defines VDSO symbols
2018-01-06 Palmer Dabbelt <palmer@sifive.com>
* sysdeps/unix/sysv/linux/dl-vdso.h (VDSO_NAME_LINUX_4_15): New
define.
(VDSO_HASH_LINUX_4_15): Likewise.
|
|
This follows ccf970c7a ('posix: Add compat glob symbol to not follow
dangling symbols') by adding to gnu/ the same compatibility as for Linux.
* sysdeps/gnu/glob64.c (__glob): Define macro instead of glob macro.
(__glob64): Define GLIBC_2_27 versioned symbol instead of glob64.
* sysdeps/gnu/glob-lstat-compat.c: New file.
* sysdeps/gnu/glob64-lstat-compat.c: New file.
|
|
* sysdeps/i386/fpu/libm-test-ulps: Regenerated for GCC 7 with
"-O2 -march=i686".
|
|
* sysdeps/i386/dl-tlsdesc.S (_dl_tlsdesc_dynamic) [NO_RTLD_HIDDEN]: Call
JUMPTARGET (___tls_get_addr) instead of HIDDEN_JUMPTARGET (___tls_get_addr).
* sysdeps/x86_64/dl-tlsdesc.S (_dl_tlsdesc_dynamic): Likewise.
|
|
* sysdeps/mach/hurd/i386/jmp_buf-macros.h: New file.
|
|
The function _itoa_word() writes characters from the higher address to
the lower address, requiring the destination string to reserve that size
before calling it.
* sysdeps/powerpc/powerpc64/dl-machine.c (_dl_reloc_overflow):
Reserve 16 chars to reloc_addr before calling _itoa_word.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Add a test to check that the getrlimit, setrlimit and prlimit functions
and their 64-bit equivalent behave correctly with RLIM_INFINITY and
RLIM64_INFINITY. For that it assumes that the prlimit64 function calls
the syscall directly without translating the value and that the kernel
uses the -1 value to represent infinity.
It first finds a resource with the hard limit set to infinity so the
soft limit can be manipulated easily and check for the consistency
between the value set or get by the prlimit64 and the other functions.
It is Linux specific add it uses the prlimit and prlimit64 functions.
Changelog:
* sysdeps/unix/sysv/linux/tst-rlimit-infinity.c: New file.
* sysdeps/unix/sysv/linux/Makefile (tests): Add tst-rlimit-infinity.
|
|
prlimit called without a new value fails on 32-bit machines if any of
the soft or hard limits are infinity. This is because prlimit does not
translate old_rlimit from RLIM64_INFINITY to RLIM_INFINITY, but checks
that the value returned by the prlimit64 syscall fits into a 32-bit
value, like it is done for example in getrlimit. Note that on the
other hand new_rlimit is correctly translated from RLIM_INFINITY to
RLIM64_INFINITY before calling the syscall.
This patch fixes that.
Changelog:
[BZ #22678]
* sysdeps/unix/sysv/linux/prlimit.c (prlimit): Translate
old_rlimit from RLIM64_INFINITY to RLIM_INFINITY.
|
|
Fix the RLIM_INFINITY and RLIM64_INFINITY constants on alpha to match
the kernel one and all other architectures. Change the getrlimit,
getrlimit64, setrlimit, setrlimit64 into old compat symbols, and provide
the Linux generic functions as GLIBC_2_27 version.
Changelog:
* sysdeps/unix/sysv/linux/getrlimit64.c [USE_VERSIONED_RLIMIT]: Do not
define getrlimit and getrlimit64 as weak aliases of __getrlimit64.
Define __GI_getrlimit64 as weak alias of __getrlimit64.
[__RLIM_T_MATCHES_RLIM64_T]: Do not redefine SHLIB_COMPAT, use #elif
instead.
* sysdeps/unix/sysv/linux/setrlimit64.c [USE_VERSIONED_RLIMIT]: Do not
define setrlimit and setrlimit64 as weak aliases of __setrlimit64.
* sysdeps/unix/sysv/linux/alpha/bits/resource.h (RLIM_INFINITY,
RLIM64_INFINITY): Fix values to match the kernel ones.
* sysdeps/unix/sysv/linux/alpha/getrlimit64.c: Define
USE_VERSIONED_RLIMIT. Rename __getrlimit64 into __old_getrlimit64 and
provide it as getrlimit@@GLIBC_2_0 and getrlimit64@@GLIBC_2_1. Add a
__getrlimit64 function and provide it as getrlimit@@GLIBC_2_27 and
getrlimit64@@GLIBC_2_27.
* sysdeps/unix/sysv/linux/alpha/setrlimit64.c: Ditto with setrlimit
and setrlimit64.
* sysdeps/unix/sysv/linux/alpha/libc.abilist (GLIBC_2.27): Add
getrlimit, setrlimit, getrlimit64 and setrlimit64.
* sysdeps/unix/sysv/linux/alpha/Versions (libc): Add getrlimit,
setrlimit, getrlimit64 and setrlimit64.
|
|
#22648]
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 the kernel side, the value is defined for the prlimit64 syscall for
all architectures in include/uapi/linux/resource.h:
#define RLIM64_INFINITY (~0ULL)
* On the kernel side, the value is defined for getrlimit and setrlimit
in arch/alpha/include/uapi/asm/resource.h
#define RLIM_INFINITY 0x7ffffffffffffffful
* On the GNU libc side, the value is defined in
sysdeps/unix/sysv/linux/alpha/bits/resource.h:
# define RLIM64_INFINITY 0x7fffffffffffffffLL
This was not an issue until the getrlimit and setrlimit glibc functions
have been changed in commit 045c13d185 ("Consolidate Linux setrlimit and
getrlimit implementation") to use the prlimit64 syscall instead of the
getrlimit and setrlimit ones.
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.
Changelog:
[BZ #22648]
* sysdeps/unix/sysv/linux/alpha/getrlimit64.c: New file.
* sysdeps/unix/sysv/linux/alpha/setrlimit64.c: Ditto.
|
|
As discussed in libc-alpha [1], alpha trunc{f} implementation uses
addt/suc and subt/suc and although the Alpha Architecture
Handbook version 3 states that that ADDx SUBx OUTPUT Exceptions
(B.3 Mapping to IEEE Standard) should not generate Inexact if INE
bit is set, the Alpha 21264 [2] chip manual (A.8 IEEE Floating-Point
Conformance) states that ADDx SUBx OUTPUT does generate inexact
exception for inexact result regardless.
As Joseph noted [3] to correctly fix it on alpha we need to either
avoid the instruction or avoid any inexact bit from it being set
on return from the function (while preserving the inexact bit that
might be set on the entry to the function). The later will result
mf_fpcr followed by a mt_fpcr to get and set the fpcr which will
defeat the optimization itself.
So the patch just remove the alpha optimized and rely on generic
implementation. It fixes the math/test-*-{trunc} on alpha.
[BZ #15479]
[BZ #22666]
* sysdeps/alpha/fpu/s_trunc.c: Remove file.
* sysdeps/alpha/fpu/s_truncf.c: Likewise.
[1] https://sourceware.org/ml/libc-alpha/2018-01/msg00114.html
[2] https://www.star.bnl.gov/public/daq/HARDWARE/21264_data_sheet.pdf
[3] https://sourceware.org/ml/libc-alpha/2018-01/msg00086.html
Signed-off-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
As discussed in libc-alpha [1], alpha ceil{f} and floor{f}
implementation uses cvttq/svm and although the Alpha Architecture
Handbook version 3 states that that CVTfi OUTPUT Exceptions
(B.3 Mapping to IEEE Standard) should not generate Inexact if INE
bit is set on fpcr, the Alpha 21264 [1] chip manual (A.8 IEEE
Floating-Point Conformance) states that CVTfi and CVTif OUTPUT
does generate inexact exception for inexact result regardless.
As Joseph noted [2] to correctly fix it on alpha we need to either
avoid the instruction or avoid any inexact bit from it being set
on return from the function (while preserving the inexact bit that
might be set on the entry to the function). The later will result
mf_fpcr followed by a mt_fpcr to get and set the fpcr which will
defeat the optimization itself.
So the patch just remove the alpha optimized and rely on generic
implementation. It fixes the math/test-*-{ceil,floor} on alpha.
[BZ #15479]
[BZ #22665]
* sysdeps/alpha/fpu/s_ceil.c: Remove file.
* sysdeps/alpha/fpu/s_ceilf.c: Likewise.
* sysdeps/alpha/fpu/s_floor.c: Likewise.
* sysdeps/alpha/fpu/s_floorf.c: Likewise.
[1] https://www.star.bnl.gov/public/daq/HARDWARE/21264_data_sheet.pdf
[2] https://sourceware.org/ml/libc-alpha/2018-01/msg00086.html
Signed-off-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Before this change, if glibc was compiled with SSE instructions and a
sufficiently recent GCC, an unaligned stack access in
__run_exit_handlers would cause stdlib/tst-makecontext to crash.
|
|
* sysdeps/mips/mips32/libm-test-ulps: Update.
* sysdeps/mips/mips64/libm-test-ulps: Likewise.
|
|
Changelog:
* sysdeps/unix/sysv/linux/alpha/getrlimit64.c (__old_getrlimit64):
Drop __RLIM_T_MATCHES_RLIM64_T conditional as __old_getrlimit64 is
never defined in that case.
|
|
Changelog:
* sysdeps/unix/sysv/linux/alpha/getrlimit64.c: Fix a typo in the
comment.
* sysdeps/unix/sysv/linux/alpha/setrlimit64.c: Fix a typo in the
comment.
(settrlimit): Rename into setrlimit.
(__sttrlimit): Rename into __setrlimit.
|
|
* sysdeps/powerpc/nofpu/libm-test-ulps: Update.
|
|
* sysdeps/arm/libm-test-ulps: Update.
|
|
Various fmax and fmin function implementations mishandle sNaN
arguments:
(a) When both arguments are NaNs, the return value should be a qNaN,
but sometimes it is an sNaN if at least one argument is an sNaN.
(b) Under TS 18661-1 semantics, if either argument is an sNaN then the
result should be a qNaN (whereas if one argument is a qNaN and the
other is not a NaN, the result should be the non-NaN argument).
Various implementations treat sNaNs like qNaNs here.
One way to fix that is to detect the sNaN and add a special case. That
said there is no FPU instruction to do that, so it requires transfering
the FP value to an integer register and testing bits. This becomes quite
complicated so it's probably better to just use the generic versions of
these functions which just do that through issignaling.
Changelog:
[BZ #22660]
* sysdeps/alpha/fpu/s_fmax.S: Remove file.
* sysdeps/alpha/fpu/s_fmaxf.S: Likewise.
* sysdeps/alpha/fpu/s_fmin.S: Likewise.
* sysdeps/alpha/fpu/s_fminf.S: Likewise.
|
