about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* hurd: Remove lingering references to the time functionFlorian Weimer2019-11-071-2/+2
| | | | | | | | They cause a check-localplt failure after commit f9a7554009cf38f39. Fixes: f9a7554009cf38f390e74fcabc5b49f974f72382 Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Change-Id: I37bc20f3449b9e358f32879ed231720c969965b4
* math: enhance the endloop condition of function handle_input_flagliqingqing2019-11-071-1/+1
| | | | | | | | In the function handle_input_flag, the end-loop condition is not correct, because when the loop variable i equals 16 (num_input_flag_types), then input_flags[16] will be out of bounds. (This issue is only relevant with invalid input files to gen-auto-libm-tests.)
* nptl: Refactor thrd_sleep in terms of clock_nanosleepAdhemerval Zanella2019-11-061-12/+9
| | | | | | Checked on x86_64-linux-gnu and powerpc64le-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Refactor nanosleep in terms of clock_nanosleepAdhemerval Zanella2019-11-067-138/+59
| | | | | | | | | | | | | The generic version is straightforward. For Hurd, its nanosleep implementation is moved to clock_nanosleep with adjustments from generic unix implementation. The generic clock_nanosleep unix version is also removed since it calls nanosleep. Checked on x86_64-linux-gnu and powerpc64le-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* nptl: Move nanosleep implementation to libcAdhemerval Zanella2019-11-0631-60/+5
| | | | | | | | | Checked on x86_64-linux-gnu and powerpc64le-linux-gnu. I also checked the libpthread.so .gnu.version_d entries for every ABI affected and all of them contains the required versions (including for architectures which exports __nanosleep with a different version). Reviewed-by: Florian Weimer <fweimer@redhat.com>
* posix: Sync regex with gnulibAdhemerval Zanella2019-11-065-114/+49
| | | | | | | | | | | | | It sync with gnulib commit 6cfb4302b3e1da14d706198b693558290e9b00f4 and contains the fixes: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=32915b2a8a43825720755113bdffe9f67a591748 https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=48f07576b8cd935b48e1050551f45ab1a79b9f01 https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=5e407aba1f775d51b25481cb55f324c9868f62d7 https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4e02b30c761c76d04057fa5f6bba71401f9310cd https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=79f8ee4e389f8cb1339f8abed9a7d29816e2a2d4 Checked on x86_64-linux-gnu and i686-linux-gnu.
* Add mnw language code [BZ #25139]Mike FABIAN2019-11-061-0/+1
|
* Add new locale: mnw_MM (Mon language spoken in Myanmar) [BZ #25139]Talachan Mon2019-11-063-0/+290
|
* S390: Fp comparison are now raising FE_INVALID with gcc 10.Stefan Liebler2019-11-061-5/+7
| | | | | | | The s390 gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77918 "S390: Floating point comparisons don't raise invalid for unordered operands." is fixed with gcc 10. Thus we conditionally set FIX_COMPARE_INVALID to 0 or 1.
* linux: pselect: Remove CALL_PSELECT6 macroLukasz Majewski2019-11-051-9/+2
| | | | | | | | Nothing defines CALL_PSELECT6 in the current tree, so remove it. Tested with: - make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8" (x86_64) - scripts/build-many-glibcs.py
* Fix run-one-test so that it runs elf testsArjun Shankar2019-11-051-1/+1
| | | | | | | | | The `test' make target passes a trailing slash in the subdir argument. This does not play well with elf/rtld-Rules which looks for `elf' without any trailing slash, and therefore doesn't find a match when running an elf test individually. This commit removes the trailing slash from the invocation. Reviewed-by: DJ Delorie <dj@redhat.com>
* nptl: Fix niggles with pthread_clockjoin_npMike Crowe2019-11-044-3/+14
| | | | | | | | | | | | | | | | | | | Joseph Myers spotted[1] that 69ca4b54c151cec42ccca5e05790efc1a8206b47 added pthread_clockjoin_np to sysdeps/nptl/pthread.h but not to its hppa-specific equivalent sysdeps/unix/sysv/linux/hppa/pthread.h. Rafal Luzynski spotted[2] typos in the NEWS entry and manual updates too. Florian Weimer spotted[3] that the clockid parameter was not using a reserved identifier in pthread.h. [1] https://sourceware.org/ml/libc-alpha/2019-11/msg00016.html [2] https://sourceware.org/ml/libc-alpha/2019-11/msg00019.html [3] https://sourceware.org/ml/libc-alpha/2019-11/msg00022.html Reviewed-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Rafal Luzynski <digitalfreak@lingonborough.com> Reviewed-by: Florian Weimer <fw@deneb.enyo.de>
* hppa: Align __clone stack argument to 8 bytes (Bug 25066)John David Anglin2019-11-031-2/+7
| | | | | | | | | The hppa architecture requires strict alignment for loads and stores. As a result, the minimum stack alignment that will work is 8 bytes. This patch adjusts __clone() to align the stack argument passed to it. It also adjusts slightly some formatting. This fixes the nptl/tst-tls1 test.
* y2038: linux: Provide __futimens64 implementationLukasz Majewski2019-11-022-3/+26
| | | | | | | | | | | | | | | | | | | This patch provides new __futimens64 explicit 64 bit function for setting access and modification time of file (by using its file descriptor). Moreover, a 32 bit version - __futimens has been refactored to internally use __futimens64. The __futimens is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversions to 64 bit struct __timespec64. When pointer to struct __timespec64 is NULL - the file access and modification time is set to the current one (by the kernel) and no conversions from struct timespec to __timespec64 are performed. The __futimens64 reuses __utimensat64_helper defined for __utimensat64. The test procedure for __futimens64 is the same as for __utimensat64 conversion patch.
* y2038: linux: Provide __utimensat64 implementationLukasz Majewski2019-11-022-4/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new __utimensat64 explicit 64 bit function for setting access and modification time of a file. Moreover, a 32 bit version - __utimensat has been refactored to internally use __utimensat64. The __utimensat is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversions to 64 bit struct __timespec64. When pointer to struct __timespec64 is NULL - the file access and modification time is set to the current one and no conversions from struct timespec to __timespec64 are performed. The new utimensat_time64 syscall available from Linux 5.1+ has been used, when applicable. The new helper function - __utimensat64_helper - has been introduced to facilitate code re-usage on function providing futimens syscall handling. The Linux kernel checks if passed tv_nsec value overflows, so there is no need to repeat it in glibc. When utimensat syscall on systems supporting 32 bit time ABI is used, the check is performed if passed data (which may have 64 bit tv_sec) fits into 32 bit range. Build tests: - The code has been tested on x86_64/x86 (native compilation): make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8" - The glibc has been build tested (make PARALLELMFLAGS="-j8") for x86 (i386), x86_64-x32, and armv7 Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master - Use of cross-test-ssh.sh for ARM (armv7): make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck Linux kernel, headers and minimal kernel version for glibc build test matrix: - Linux v5.1 (with utimensat_time64) and glibc build with v5.1 as minimal kernel version (--enable-kernel="5.1.0") The __ASSUME_TIME64_SYSCALLS flag defined. - Linux v5.1 and default minimal kernel version The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports utimensat_time64 syscall. - Linux v4.19 (no utimensat_time64 support) with default minimal kernel version for contemporary glibc This kernel doesn't support utimensat_time64 syscall, so the fallback to utimensat is tested. The above tests were performed with Y2038 redirection applied as well as without (so the __TIMESIZE != 64 execution path is checked as well). No regressions were observed.
* nptl: Add pthread_timedjoin_np, pthread_clockjoin_np NULL timeout testMike Crowe2019-11-012-0/+75
| | | | | | | | | | | Passing NULL as the timeout parameter to pthread_timedjoin_np has resulted in it behaving like pthread_join for a long time. Since that is now the documented behaviour, we ought to test that both it and the new pthread_clockjoin_np support it. Checked on x86_64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* nptl: Add pthread_clockjoin_npMike Crowe2019-11-0145-28/+235
| | | | | | | | | | | Introduce pthread_clockjoin_np as a version of pthread_timedjoin_np that accepts a clockid_t parameter to indicate which clock the timeout should be measured against. This mirrors the recently-added POSIX-proposed "clock" wait functions. Checked on x86_64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* manual: Add documentation for pthread_tryjoin_np and pthread_timedjoin_npMike Crowe2019-11-011-2/+24
| | | | Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* nptl: Convert tst-join3 to use libsupportMike Crowe2019-11-011-66/+20
| | | | | | Checked on x86_64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Sync time/mktime.c with gnulibPaul Eggert2019-10-311-1/+1
| | | | | This syncs with gnulib commit 9e78024bad107fe786cc3e5e328a475921ea0873. * time/mktime.c: Update URL in comment.
* Sync timespec-{add,sub} with gnulibAdhemerval Zanella2019-10-312-26/+14
| | | | | | It sync with gnulib commit 06011ed74e978613422aca43c0bd92dc44213933. Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
* Sync intprops.h with gnulibAdhemerval Zanella2019-10-311-45/+169
| | | | | | It sync with gnulib commit f5756b919addb9e8ce03f4e61a10e4fcff14874a. Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
* Refactor adjtimex based on clock_adjtimeAdhemerval Zanella2019-10-313-2/+7
| | | | | | Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Refactor PI mutexes internal definitionsAdhemerval Zanella2019-10-317-69/+137
| | | | | | | | | | This patch adds the generic futex_lock_pi and futex_unlock_pi to wrap around the syscall machinery required to issue the syscall calls. It simplifies a bit the futex code required to implement PI mutexes. No function changes, checked on x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Remove pause and nanosleep not cancel wrappersAdhemerval Zanella2019-10-315-76/+2
| | | | | | Since they are not used any longer. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* nptl: Replace non cancellable pause/nanosleep with futexAdhemerval Zanella2019-10-317-82/+56
| | | | | | | | | | | | | | | | | | | | | | | | To help y2038 work avoid duplicate all the logic of nanosleep on non cancellable version, the patch replace it with a new futex operation, lll_timedwait. The changes are: - Add a expected value for __lll_clocklock_wait, so it can be used to wait for generic values. - Remove its internal atomic operation and move the logic to __lll_clocklock. It makes __lll_clocklock_wait even more generic and __lll_clocklock slight faster on fast-path (since it won't require a function call anymore). - Add lll_timedwait, which uses __lll_clocklock_wait, to replace both __pause_nocancel and __nanosleep_nocancel. It also allows remove the sparc32 __lll_clocklock_wait implementation (since it is similar to the generic one). Checked on x86_64-linux-gnu, sparcv9-linux-gnu, and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Consolidate lowlevellock-futex.hAdhemerval Zanella2019-10-312-205/+128
| | | | | | | | | | NPTL is already Linux specific, there is no need to parametrize low level lock futex operations and add a sysdep Linux specific implementation. This patch moves the relevant Linux code to nptl one. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Consolidate futex-internal.hAdhemerval Zanella2019-10-312-270/+196
| | | | | | | | | | NPTL is already Linux specific, there is no need to parametrize futex operations and add a sysdep Linux specific implementation. This patch moves the relevant Linux code to nptl one. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Base max_fast on alignment, not width, of bins (Bug 24903)DJ Delorie2019-10-301-1/+1
| | | | | | | | | | | | set_max_fast sets the "impossibly small" value based on, eventually, MALLOC_ALIGNMENT. The comparisons for the smallest chunk used is, eventually, MIN_CHUNK_SIZE. Note that i386 is the only platform where these are the same, so a smallest chunk *would* be put in a no-fastbins fastbin. This change calculates the "impossibly small" value based on MIN_CHUNK_SIZE instead, so that we can know it will always be impossibly small.
* Revise the documentation of simple calendar time.Zack Weinberg2019-10-304-471/+611
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a thorough revision of all the material relating to the functions time, stime, gettimeofday, settimeofday, clock_gettime, clock_getres, clock_settime, and difftime, spilling over into the discussion of time-related data types (which now get their own section) and touching the adjtime family as well (which deserves its own thorough revision, but I'd have to do a bunch of research first). Substantive changes are: * Document clock_gettime, clock_getres, and clock_settime. (Only CLOCK_REALTIME and CLOCK_MONOTONIC are documented; the others are either a bit too Linux-specific, or have more to do with measuring CPU/processor time. That section _also_ deserves its own thorough revision but again I'd have to do a bunch of research first.) * Present gettimeofday, settimeofday, and struct timeval as obsolete relative to clock_*. * Remove the documentation of struct timezone. Matching POSIX, say that the type of the second argument to gettimeofday and settimeofday is [const] void *. * Clarify ISO C and POSIX's requirements on time_t. Clarify the circumstances under which difftime is equivalent to simple subtraction. * Consolidate documentation of most of the time-related data types into a new section "Time Types," right after "Time Basics." (The exceptions are struct tm, which stays in "Broken-down Time," and struct times, which stays in "Processor And CPU Time." * The "Elapsed Time" section is now called "Calculating Elapsed Time" and includes only difftime and the discussion of how to compute timeval differences by hand. * Fold the "Simple Calendar Time," "High Resolution Calendar," and "High Accuracy Clock" sections together into two new sections titled "Getting the Time" and "Setting and Adjusting the Time."
* Make second argument of gettimeofday as 'void *'Zack Weinberg2019-10-306-20/+21
| | | | | | | | | | | | | Also make the public prototype of gettimeofday declare its second argument with type "void *" unconditionally, consistent with POSIX. It is also consistent with POSIX. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Use clock_gettime to implement gettimeofday.Adhemerval Zanella2019-10-3016-309/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consolidate generic gettimeofday implementation to use clock_gettime. Linux ports that still provide gettimeofday through vDSO are not changed. Remove sysdeps/unix/clock_gettime.c, which implemented clock_gettime using gettimeofday; new OS ports must provide a real implementation of clock_gettime. Rename sysdeps/mach/gettimeofday.c to sysdeps/mach/clock_gettime.c and convert into an implementation of clock_gettime. It only supports CLOCK_REALTIME; Mach does not appear to have any support for monotonic clocks. It uses __host_get_time, which provides at best microsecond resolution. Hurd is currently using sysdeps/posix/clock_getres.c for clock_getres; its output for CLOCK_REALTIME is based on sysconf (_SC_CLK_TCK), and I do not know whether that gives the correct result. Unlike settimeofday, there are no known uses of gettimeofday's vestigial "get time zone" feature that are not bugs. (The per-process timezone support in localtime and friends is unrelated, and the programs that set the kernel's offset between the hardware clock and UTC do not need to read it back.) Therefore, this feature is dummied out. Henceforth, if gettimeofday's "struct timezone" argument is not NULL, it will write zeroes to both fields. Any program that is actually looking at this data will thus think it is running in UTC, which is probably more correct than whatever it was doing before. [__]gettimeofday no longer has any internal callers, so we can now remove its internal prototype and PLT bypass aliases. The __gettimeofday@GLIBC_2.0 export remains, in case it is used by any third-party code. It also allows to simplify the arch-specific implementation on x86 and powerpc to remove the hack to disable the internal route to non iFUNC variant for internal symbol. This patch also fixes a missing optimization on aarch64, powerpc, and x86 where the code used on static build do not use the vDSO. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Co-authored-by: Zack Weinberg <zackw@panix.com> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Use clock_gettime to implement timespec_get.Zack Weinberg2019-10-303-88/+4
| | | | | | | | | | | | | | | | | | | | | timespec_get is the same function as clock_gettime, with an obnoxious coating of NIH painted on it by the ISO C committee. In addition to the rename, it takes its arguments in a different order, it returns 0 on *failure* or a positive number on *success*, and it requires that all of its TIME_* constants be positive. This last means we cannot directly reuse the existing CLOCK_* constants for it, because those have been allocated starting with CLOCK_REALTIME = 0 on all existing platforms. This patch simply promotes the sysdeps/posix implementation to universal, and removes the Linux-specific implementation, whose apparent reason for existing was to cut out one function call's worth of overhead. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Consolidate and deprecate ftimeZack Weinberg2019-10-306-61/+21
| | | | | | | | | | | | | | | | | | | | | | | | | ftime is an obsolete variation on gettimeofday, offering only millisecond time resolution; it was probably a system call in ooold versions of BSD Unix. For historic reasons, we had three implementations of it. These are all consolidated into time/ftime.c, and then the function is deprecated. For some reason, the implementation of ftime in terms of gettimeofday was rounding rather than truncating microseconds to milliseconds. In all the other places where we use a higher-resolution time function to implement a lower-resolution one, we truncate. ftime is changed to match, just for tidiness' sake. Like gettimeofday, ftime tries to report the time zone, and using that information is always a bug. This patch dummies out the reported timezone information; the timezone and dstflag fields of the returned "struct timeb" will always be zero. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, and powerpc-linux-gnu. Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Change most internal uses of time to __clock_gettime.Adhemerval Zanella2019-10-3014-121/+53
| | | | | | | | | | | | | | | | | As for gettimeofday, time will be implemented based on clock_gettime on all platforms and internal code should use clock_gettime directly. In addition to removing a layer of indirection, this will allow us to remove the PLT-bypass gunk for gettimeofday. The changed code always assumes __clock_gettime (CLOCK_REALTIME) or __clock_gettime (CLOCK_REALTIME_COARSE) (for Linux case) cannot fail, using the same rationale for gettimeofday change. And internal helper was added (time_now). Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, and powerpc-linux-gnu. Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Use clock_gettime to implement time.Adhemerval Zanella2019-10-304-57/+17
| | | | | | | | | | | | | | | | | Change the default implementation of time to call clock_gettime, to align with new Linux ports that are expected to only implement __NR_clock_gettime. Arch-specific implementation that either call the time vDSO or route to gettimeofday vDSO are not removed. Also for Linux, CLOCK_REALTIME_COARSE is used instead of generic CLOCK_REALTIME clockid. This takes less CPU time and its behavior better matches what the current glibc does. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Co-authored-by: Zack Weinberg <zackw@panix.com> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Use clock_settime to implement settimeofday.Zack Weinberg2019-10-3012-72/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unconditionally, on all ports, use clock_settime to implement settimeofday. Remove sysdeps/unix/clock_settime.c, which implemented clock_settime by calling settimeofday; new OS ports must henceforth provide a real implementation of clock_settime. Hurd had a real implementation of settimeofday but not of clock_settime; this patch converts it into an implementation of clock_settime. It only supports CLOCK_REALTIME and microsecond resolution; Hurd/Mach does not appear to have any support for finer-resolution clocks. The vestigial "set time zone" feature of settimeofday complicates the generic settimeofday implementation a little. The only remaining uses of this feature that aren't just bugs, are using it to inform the Linux kernel of the offset between the hardware clock and UTC, on systems where the hardware clock doesn't run in UTC (usually because of dual-booting with Windows). There currently isn't any other way to do this. However, the callers that do this call settimeofday with _only_ the timezone argument non-NULL. Therefore, glibc's new behavior is: callers of settimeofday must supply one and only one of the two arguments. If both arguments are non-NULL, or both arguments are NULL, the call fails and sets errno to EINVAL. When only the timeval argument is supplied, settimeofday calls __clock_settime(CLOCK_REALTIME), same as stime. When only the timezone argument is supplied, settimeofday calls a new internal function called __settimezone. On Linux, only, this function will pass the timezone structure to the settimeofday system call. On all other operating systems, and on Linux architectures that don't define __NR_settimeofday, __settimezone is a stub that always sets errno to ENOSYS and returns -1. The settimeoday syscall is enabled on Linux by the flag COMPAT_32BIT_TIME, which is an option to either 32-bits ABIs or COMPAT builds (defined usually by 64-bit kernels that want to support 32-bit ABIs, such as x86). The idea to future 64-bit time_t only ABIs is to not provide settimeofday syscall. The same semantics are implemented for Linux/Alpha's GLIBC_2.0 compat symbol for settimeofday. There are no longer any internal callers of __settimeofday, so the internal prototype is removed. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Use clock_settime to implement stime; withdraw stime.Zack Weinberg2019-10-305-58/+17
| | | | | | | | | | | | Unconditionally, on all ports, use clock_settime to implement stime, not settimeofday or a direct syscall. Then convert stime into a compatibility symbol and remove its prototype from time.h. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Change most internal uses of __gettimeofday to __clock_gettime.Zack Weinberg2019-10-3026-137/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since gettimeofday will shortly be implemented in terms of clock_gettime on all platforms, internal code should use clock_gettime directly; in addition to removing a layer of indirection, this will allow us to remove the PLT-bypass gunk for gettimeofday. (We can't quite do that yet, but it'll be coming later in this patch series.) In many cases, the changed code does fewer conversions. The changed code always assumes __clock_gettime (CLOCK_REALTIME) cannot fail. Most of the call sites were assuming gettimeofday could not fail, but a few places were checking for errors. POSIX says clock_gettime can only fail if the clock constant is invalid or unsupported, and CLOCK_REALTIME is the one and only clock constant that's required to be supported. For consistency I grepped the entire source tree for any other places that checked for errors from __clock_gettime (CLOCK_REALTIME), found one, and changed it too. (For the record, POSIX also says gettimeofday can never fail.) (It would be nice if we could declare that GNU systems will always support CLOCK_MONOTONIC as well as CLOCK_REALTIME; there are several places where we are using CLOCK_REALTIME where _MONOTONIC would be more appropriate, and/or trying to use _MONOTONIC and then falling back to _REALTIME. But the Hurd doesn't support CLOCK_MONOTONIC yet, and it looks like adding it would involve substantial changes to gnumach's internals and API. Oh well.) A few Hurd-specific files were changed to use __host_get_time instead of __clock_gettime, as this seemed tidier. We also assume this cannot fail. Skimming the code in gnumach leads me to believe the only way it could fail is if __mach_host_self also failed, and our Hurd-specific code consistently assumes that can't happen, so I'm going with that. With the exception of support/support_test_main.c, test cases are not modified, mainly because I didn't want to have to figure out which test cases were testing gettimeofday specifically. The definition of GETTIME in sysdeps/generic/memusage.h had a typo and was not reading tv_sec at all. I fixed this. It appears nobody has been generating malloc traces on a machine that doesn't have a superseding definition. There are a whole bunch of places where the code could be simplified by factoring out timespec subtraction and/or comparison logic, but I want to keep this patch as mechanical as possible. Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, powerpc64-linux-gnu, powerpc-linux-gnu, and aarch64-linux-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Lukasz Majewski <lukma@denx.de>
* Linux/Alpha: don't use timeval32 system calls.Zack Weinberg2019-10-3018-131/+637
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux/Alpha has two versions of several system call wrappers that take or return data of type "struct timeval" (possibly nested inside a larger structure). The GLIBC_2.0 version is a compat symbol that calls __NR_osf_foo or __NR_old_foo and uses a struct timeval with a 32-bit tv_sec field. The GLIBC_2.1 version is used for current code, calls __NR_foo, and uses a struct timeval with a 64-bit tv_sec field. This patch changes all of the compat symbols of this type to be wrappers around their GLIBC_2.1 counterparts; the compatibility system calls will no longer be used. It serves as a proposal for part of how we do the transition to 64-bit time_t on systems that currently use 32-bit time_t: * The patched glibc will NOT use system calls that involve 32-bit time_t to implement its compatibility symbols. This will make both our lives and the kernel maintainers' lives easier. The primary argument I've seen against it is that the kernel could warn about uses of the old system calls, helping people find old binaries that need to be recompiled. I think there are several other ways we could accomplish this, e.g. scripts to scan the filesystem for binaries with references to the old symbol versions, or issuing diagnostics ourselves. * The compat symbols do NOT report failure after the Y2038 deadline. An earlier revision of this patch had them return -1 and set errno to EOVERFLOW, but Adhemerval pointed out that many of them have already performed side effects at the point where we discover the overflow, so that would break more than it fixes. Also, we don't want people to be _checking_ for EOVERFLOW from these functions; we want them to recompile with 64-bit time_t. So it's not actually useful for them to report failure to the calling code. * What they do do, when they encounter overflow, is saturate the overflowed "struct timeval"(s): tv_sec is set to INT32_MAX and tv_nsec is set to 999999. That means time stops advancing for programs with 32-bit time_t when they reach the deadline. That's obviously going to break stuff, but I think wrapping around is probably going to break _more_ stuff. I'd be interested to hear arguments against, if anyone has one. The new header file tv32-compat.h is currently Alpha-specific but I mean for it to be reused to aid in writing wrappers for all affected architectures. I only put it in sysdeps/unix/sysv/linux/alpha for now because I haven't checked whether the various "foo32" structures it defines agree with the ABI for ports other than Linux/Alpha. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* resolv/tst-idna_name_classify: Isolate from system librariesFlorian Weimer2019-10-301-0/+4
| | | | | Loading NSS modules from static binaries uses installed system libraries if LD_LIBRARY_PATH is not set.
* hurd: Support for file record lockingSvante Signell2019-10-301-24/+87
| | | | | | * sysdeps/mach/hurd/fcntl.c: Add support for file-record-lock RPC fixing posix file locking using the flock64 version of struct flock.
* Comment out initgroups from example nsswitch.conf (Bug 25146)Carlos O'Donell2019-10-291-1/+2
| | | | | | | | | | In commit 4b7c74179c8928d971d370e1137d202f891a4cf5 the nsswitch.conf file was harmonized with downstream distributions, but this change included adding "initgroups: files". We should not add initgroups by default, we can have it, but it should be commented out to allow it to inherit the settings for group. The problem is principally that downstream authconfig won't update initgroups and it will get out of sync with the setting for group.
* y2038: linux: Provide __clock_getres64 implementationLukasz Majewski2019-10-272-3/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new __clock_getres64 explicit 64 bit function for getting the resolution (precision) of specified clock ID. Moreover, a 32 bit version - __clock_getres has been refactored to internally use __clock_getres64. The __clock_getres is now supposed to be used on systems still supporting 32 bit time (__TIMESIZE != 64) - hence the necessary conversion from 64 bit struct __timespec64 to struct timespec. The new clock_getres_time64 syscall available from Linux 5.1+ has been used, when applicable. On systems which are not supporting clock_getres_time64 (as their clock_getres supports 64 bit time ABI) the vDSO syscall is attempted. On the contrary the non-vDSO syscall is used for clock_getres_time64 as up till now the kernel is not providing such interface. No additional checks (i.e. if tv_nsec value overflow) are performed on values returned via clock_getres{_time64} syscall, as it is assumed that the Linux kernel will either return 0 and provide correct value or error. The check for tv_sec being out of range on systems still supporting 32 bit time (__TIMESIZE != 64) without Y2038 time support is also omitted as it is _very_ unlikely that we would have a timer with resolution which exceeds 32 bit time_t range. Build tests: - The code has been tested on x86_64/x86 (native compilation): make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8" - The glibc has been build tested (make PARALLELMFLAGS="-j8") for x86 (i386), x86_64-x32, and armv7 Run-time tests: - Run specific tests on ARM/x86 32bit systems (qemu): https://github.com/lmajewski/meta-y2038 and run tests: https://github.com/lmajewski/y2038-tests/commits/master - Use of cross-test-ssh.sh for ARM (armv7): make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck Linux kernel, headers and minimal kernel version for glibc build test matrix: - Linux v5.1 (with clock_getres_time64) and glibc build with v5.1 as minimal kernel version (--enable-kernel="5.1.0") The __ASSUME_TIME64_SYSCALLS flag defined. - Linux v5.1 and default minimal kernel version The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports clock_getres_time64 syscall. - Linux v4.19 (no clock_getres_time64 support) with default minimal kernel version for contemporary glibc This kernel doesn't support clock_getres_time64 syscall, so the fallback to clock_getres is tested. The above tests were performed with Y2038 redirection applied as well as without (so the __TIMESIZE != 64 execution path is checked as well). No regressions were observed.
* time: Introduce function to check correctness of nanoseconds valueLukasz Majewski2019-10-2724-36/+49
| | | | | | | | | | | | | | | The valid_nanoseconds () static inline function has been introduced to check if nanoseconds value is in the correct range - greater or equal to zero and less than 1000000000. The explicit #include <time.h> has been added to files where it was missing. The __syscall_slong_t type for ns has been used to avoid issues on x32. Tested with: - scripts/build-many-glibcs.py - make PARALLELMFLAGS="-j12" && make PARALLELMFLAGS="-j12" xcheck on x86_64
* Add Transliterations for Unicode Misc. Mathematical Symbols-A/B [BZ #23132]Arjun Shankar2019-10-253-3/+157
| | | | | | | | | This commit adds previously missing transliterations for several code points in the Unicode blocks "Miscellaneous Mathematical Symbols-A/B" - transliterated to their approximate ASCII representations. It also adds a corresponding iconv transliteration test. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Install charmaps uncompressed in testrootDJ Delorie2019-10-242-1/+26
| | | | | | | | | | | | | The testroot does not have a gunzip command, so the charmap files should not be installed gzipped else they cannot be used (and thus tested). With this patch, installing with INSTALL_UNCOMPRESSED=yes installs uncompressed charmaps instead. Note that we must purge the $(symbolic_link_list) as it contains references to $(DESTDIR), which we change during the testroot installation. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Add wait-for-debugger test harness hooksDJ Delorie2019-10-242-0/+75
| | | | | | | | If WAIT_FOR_DEBUGGER is set to a non-zero value in the environment, any test that runs will print some useful gdb information and wait for gdb to attach to it and clear the "wait_for_debugger" variable. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Define __STATFS_MATCHES_STATFS64Alistair Francis2019-10-249-2/+37
| | | | | | | | Add a new macro __STATFS_MATCHES_STATFS64 that specifies if fsblkcnt_t matches fsblkcnt64_t and if fsfilcnt_t matches fsfilcnt64_t. As we don't have the padding we also need to update the overflow checker to not access the undefined members.
* hurd: Fix build after __pread64 usage in the dynamic loaderFlorian Weimer2019-10-241-3/+11
| | | | | | | | | | | Commit 95c1056962a3f2297c94ce47f0eaf0c5b6563231 ("elf: Use nocancel pread64() instead of lseek()+read()") added calls to __pread64 to the dynamic loader. On Hurd, this needs an implementation in the dynamic loader because the rtld-pread64 rebuild pulls in too many symbols. Fixes: 95c1056962a3f2297c94ce47f0eaf0c5b6563231 Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>