about summary refs log tree commit diff
path: root/manual
Commit message (Collapse)AuthorAgeFilesLines
* Fix strnlen doc re array sizePaul Eggert2024-06-261-7/+10
| | | | | | | | | * manual/string.texi: For strnlen (s, maxlen), do not say that s must be of size maxlen, as it can be smaller if it is null-terminated. This should help avoid confusion such as seen in <https://lists.gnu.org/r/bug-gnulib/2024-06/msg00280.html>. Mention that strnlen and wcsnlen have been in POSIX since POSIX.1-2008.
* INSTALL: Fix typo ibmlondouble to ibmlongdoubleJoe Simmons-Talbott2024-06-241-1/+1
|
* elf: Remove LD_HWCAP_MASK / tunable glibc.cpu.hwcap_maskStefan Liebler2024-06-182-17/+6
| | | | | | | | | | | | Remove the environment variable LD_HWCAP_MASK and the tunable glibc.cpu.hwcap_mask as those are not used anymore in common-code after removal in elf/dl-cache.c:search_cache(). The only remaining user is sparc32 where it is used in elf_machine_matches_host(). If sparc32 does not need it anymore, we can get rid of it at all. Otherwise we could also move LD_HWCAP_MASK / tunable glibc.cpu.hwcap_mask to be sparc32 specific. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Convert to autoconf 2.72 (vanilla release, no distribution patches)Andreas K. Hüttel2024-06-171-1/+1
| | | | | | | As discussed at the patch review meeting Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> Reviewed-by: Simon Chopin <simon.chopin@canonical.com>
* Implement C23 exp2m1, exp10m1Joseph Myers2024-06-171-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
* Implement C23 log10p1Joseph Myers2024-06-171-0/+14
| | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the log10p1 functions (log10(1+x): like log1p, but for base-10 logarithms). This is directly analogous to the log2p1 implementation (except that whereas log2p1 has a smaller underflow range than log1p, log10p1 has a larger underflow range). The test inputs are copied from those for log1p and log2p1, plus a few more inputs in that wider underflow range. Tested for x86_64 and x86, and with build-many-glibcs.py.
* Implement C23 logp1Joseph Myers2024-06-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the logp1 functions (aliases for log1p functions - the name is intended to be more consistent with the new log2p1 and log10p1, where clearly it would have been very confusing to name those functions log21p and log101p). As aliases rather than new functions, the content of this patch is somewhat different from those actually adding new functions. Tests are shared with log1p, so this patch *does* mechanically update all affected libm-test-ulps files to expect the same errors for both functions. The vector versions of log1p on aarch64 and x86_64 are *not* updated to have logp1 aliases (and thus there are no corresponding header, tests, abilist or ulps changes for vector functions either). It would be reasonable for such vector aliases and corresponding changes to other files to be made separately. For now, the log1p tests instead avoid testing logp1 in the vector case (a Makefile change is needed to avoid problems with grep, used in generating the .c files for vector function tests, matching more than one ALL_RM_TEST line in a file testing multiple functions with the same inputs, when it assumes that the .inc file only has a single such line). Tested for x86_64 and x86, and with build-many-glibcs.py.
* Minor code improvement to timespec_subtract examplePaul Eggert2024-06-151-3/+3
| | | | | | | This saves a few instructions. BORROW cannot be -1, since NSEC_DIFF is at most 999999999. Idea taken from Gnulib, here: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fe33f943054b93af8b965ce6564b8713b0979a21
* Modernize and fix doc’s “Date and Time” (BZ 31876)Paul Eggert2024-06-158-462/+584
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | POSIX.1-2024 (now official) specifies tm_gmtoff and tm_zone. This is a good time to update the manual’s “Date and Time” chapter so I went through it, fixed some outdated stuff that had been in there for decades, and improved it to match POSIX.1-2024 better and to clarify some implementation-defined behavior. Glibc already conforms to POSIX.1-2024 in these matters, so this is merely a documentation change. * manual/examples/strftim.c: Use snprintf instead of now-deprecated function asctime. Check for localtime failure. Simplify by using puts instead of fputs. Prefer ‘buf, sizeof buf’ to less-obvious ‘buffer, SIZE’. * manual/examples/timespec_subtract.c: Modernize to use struct timespec not struct timeval, and rename from timeval_subtract.c. All uses changed. Check for overflow. Do not check for negative return value, which ought to be OK since negative time_t is OK. Use GNU indenting style. * manual/time.texi: Document CLOCKS_PER_SEC, TIME_UTC, timespec_get, timespec_getres, strftime_l. Document the storage lifetime of tm_zone and of tzname. Caution against use of tzname, timezone and daylight, saying that these variables have unspecified values when TZ is geographic. This is what glibc actually does (contrary to what the manual said before this patch), and POSIX is planned to say the same thing <https://austingroupbugs.net/view.php?id=1816>. Also say that directly accessing the variables is not thread-safe. Say that localtime_r and ctime_r don’t necessarily set time zone state. Similarly, in the tzset documentation, say that it is called by ctime, localtime, mktime, strftime, not that it is called by all time conversion functions that depend on the time zone. Say that tm_isdst is useful mostly just for mktime, and that other uses should prefer tm_gmtoff and tm_zone instead. Do not say that strftime ignores tm_gmtoff and tm_zone, because it doesn’t do that. Document what gmtime does to tm_gmtoff and tm_zone. Say that the asctime, asctime_r, ctime, and ctime_r are now deprecated and/or obsolescent, and that behavior is undefined if the year is < 1000 or > 9999. Document strftime before these now-obsolescent functions, so that readers see the useful function first. Coin the terms “geographical format” and “proleptic format” for the two main formats of TZ settings, to simplify exposition. Use this wording consistently. Update top-level proleptic syntax to match POSIX.1-2024, which glibc already implements. Document the angle-bracket quoted forms of time zone abbreviations in proleptic TZ. Say that time zone abbreviations can contain only ASCII alphanumerics, ‘+’, and ‘-’. Document what happens if the proleptic form specifies a DST abbreviation and offset but omits the rules. POSIX says this is implementation-defined so we need to document it. Although this documentation mentions ‘posixrules’ tersely, we need to rethink ‘posixrules’ since I think it stops working after 2038. Clarify wording about TZ settings beginning with ‘;’. Say that timegm is in ISO C (as of C23). Say that POSIX.1-2024 removed gettimeofday. Say that tm_gmtoff and tm_zone are extensions to ISO C, which is clearer than saying they are invisible in a struct ISO C enviroment, and gives us more wiggle room if we want to make them visible in strict ISO C, something that ISO C allows. Drop mention of old standards like POSIX.1c and POSIX.2-1992 in the text when the history is so old that it’s no longer useful in a general-purpose manual. Define Coordinated Universal Time (UTC), time zone, time zone ruleset, and POSIX Epoch, and use these phrases more consistently. Improve TZ examples to show more variety, and to reflect current practice and timestamps. Remove obsolete example about Argentina. Add an example for Ireland. Don’t rely on GCC extensions when explaining ctime_r. Do not say that difftime produces the mathematically correct result, since it might be inexact. For clock_t don’t say “as in the example above” when there is no such example, and don’t say that casting to double works “properly and consistently no matter what”, as it suffers from rounding and overflow. Don’t say broken-down time is not useful for calculations; it’s merely painful. Say that UTC is not defined before 1960. Rename Time Zone Functions to Time Zone State. All uses changed. Update Internet RFC 822 → 5322, 1305 → 5905. Drop specific years of ISO 8601 as they don’t matter. Minor style changes: @code{"..."} → @t{"..."} to avoid overquoting in info files, @code → @env for environment variables, Daylight Saving Time → daylight saving time, white space → whitespace, prime meridian → Prime Meridian.
* manual: minor language fix (bz 31340)Andreas K. Hüttel2024-06-151-1/+1
| | | | | Resolves: https://sourceware.org/bugzilla/show_bug.cgi?id=31340 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* Improve doc for time_t range (BZ 31808)Paul Eggert2024-06-041-1/+11
|
* x86: Add seperate non-temporal tunable for memsetNoah Goldstein2024-05-301-1/+15
| | | | | | | | | | | The tuning for non-temporal stores for memset vs memcpy is not always the same. This includes both the exact value and whether non-temporal stores are profitable at all for a given arch. This patch add `x86_memset_non_temporal_threshold`. Currently we disable non-temporal stores for non Intel vendors as the only benchmarks showing its benefit have been on Intel hardware. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* manual: clarify defintions of floating point exponent bounds (bug 31518)Andreas Schwab2024-05-211-5/+5
| | | | | For decimal exponent bounds the range is inclusive, for binary exponent bounds the range is exclusive.
* Implement C23 log2p1Joseph Myers2024-05-201-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | C23 adds various <math.h> function families originally defined in TS 18661-4. Add the log2p1 functions (log2(1+x): like log1p, but for base-2 logarithms). This illustrates the intended structure of implementations of all these function families: define them initially with a type-generic template implementation. If someone wishes to add type-specific implementations, it is likely such implementations can be both faster and more accurate than the type-generic one and can then override it for types for which they are implemented (adding benchmarks would be desirable in such cases to demonstrate that a new implementation is indeed faster). The test inputs are copied from those for log1p. Note that these changes make gen-auto-libm-tests depend on MPFR 4.2 (or later). The bulk of the changes are fairly generic for any such new function. (sysdeps/powerpc/nofpu/Makefile only needs changing for those type-generic templates that use fabs.) Tested for x86_64 and x86, and with build-many-glibcs.py.
* manual: add dup3DJ Delorie2024-05-131-0/+8
| | | | Reviewed-by: Florian Weimer <fweimer@redhat.com>
* LoongArch: Add glibc.cpu.hwcap support.caiyinyu2024-04-241-1/+4
| | | | | | | | | | | | | | | | The current IFUNC selection is always using the most recent features which are available via AT_HWCAP. But in some scenarios it is useful to adjust this selection. The environment variable: GLIBC_TUNABLES=glibc.cpu.hwcaps=-xxx,yyy,zzz,.... can be used to enable HWCAP feature yyy, disable HWCAP feature xxx, where the feature name is case-sensitive and has to match the ones used in sysdeps/loongarch/cpu-tunables.c. Signed-off-by: caiyinyu <caiyinyu@loongson.cn>
* aarch64: Enhanced CPU diagnostics for ld.soFlorian Weimer2024-04-081-0/+34
| | | | | | | This prints some information from struct cpu_features, and the midr_el1 and dczid_el0 system register contents on every CPU. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* x86: Add generic CPUID data dumper to ld.so --list-diagnosticsFlorian Weimer2024-04-081-1/+84
| | | | | | | | | | | This is surprisingly difficult to implement if the goal is to produce reasonably sized output. With the current approaches to output compression (suppressing zeros and repeated results between CPUs, folding ranges of identical subleaves, dealing with the %ecx reflection issue), the output is less than 600 KiB even for systems with 256 logical CPUs. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* Fix bsearch, qsort doc to match POSIX betterPaul Eggert2024-04-061-24/+36
| | | | | | | | | | | | | | | | | | | | | | * manual/search.texi (Array Search Function): Correct the statement about lfind’s mean runtime: it is proportional to a number (not that number), and this is true only if random elements are searched for. Relax the constraint on bsearch’s array argument: POSIX says it need not be sorted, only partially sorted. Say that the first arg passed to bsearch’s comparison function is the key, and the second arg is an array element, as POSIX requires. For bsearch and qsort, say that the comparison function should not alter the array, as POSIX requires. For qsort, say that the comparison function must define a total order, as POSIX requires, that it should not depend on element addresses, that the original array index can be used for stable sorts, and that if qsort still works if memory allocation fails. Be more consistent in calling the array elements “elements” rather than “objects”. Co-authored-by: Zack Weinberg <zack@owlfolio.org>
* misc: Add support for Linux uio.h RWF_NOAPPEND flagStafford Horne2024-04-041-0/+4
| | | | | | | | | | | | | | | | | | | In Linux 6.9 a new flag is added to allow for Per-io operations to disable append mode even if a file was opened with the flag O_APPEND. This is done with the new RWF_NOAPPEND flag. This caused two test failures as these tests expected the flag 0x00000020 to be unused. Adding the flag definition now fixes these tests on Linux 6.9 (v6.9-rc1). FAIL: misc/tst-preadvwritev2 FAIL: misc/tst-preadvwritev64v2 This patch adds the flag, adjusts the test and adds details to documentation. Link: https://lore.kernel.org/all/20200831153207.GO3265@brightrain.aerifal.cx/ Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* manual: significand() uses FLT_RADIX, not 2Alejandro Colomar2024-04-031-1/+1
| | | | | | | | | | | | | | It's implemented using scalb(), which uses FLT_RADIX, AFAIK. Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#mf21ab57e16b92eb6be6c7df79dc0eb43d4454056> Reported-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Cc: DJ Delorie <dj@redhat.com> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: DJ Delorie <dj@redhat.com>
* manual: Clarify return value of cbrt(3)Alejandro Colomar2024-04-031-2/+6
| | | | | | | | | | | | | Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#mff0ab388000c6afdb5e5162804d4a0073de481de> Reported-by: Morten Welinder <mwelinder@gmail.com> Cowritten-by: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Cc: DJ Delorie <dj@redhat.com> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: DJ Delorie <dj@redhat.com>
* manual: floor(log2(fabs(x))) has rounding errorsAlejandro Colomar2024-04-031-2/+5
| | | | | | | | | | | | Link: <https://inbox.sourceware.org/libc-alpha/20240305150131.GD3653@qaa.vinc17.org/T/#m3ceecda630012995339bcc5448fee451cf277a8b> Reported-by: Vincent Lefevre <vincent@vinc17.net> Suggested-by: Vincent Lefevre <vincent@vinc17.net> Reviewed-by: DJ Delorie <dj@redhat.com> Cc: Morten Welinder <mwelinder@gmail.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
* manual: logb(x) is floor(log2(fabs(x)))Alejandro Colomar2024-04-031-1/+1
| | | | | | | | | | | | | | log2(3) doesn't accept negative input, but it seems logb(3) does accept it. Link: <https://lore.kernel.org/linux-man/ZeYKUOKYS7G90SaV@debian/T/#u> Reported-by: Morten Welinder <mwelinder@gmail.com> Reviewed-by: DJ Delorie <dj@redhat.com> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Vincent Lefevre <vincent@vinc17.net> Cc: Paul Zimmermann <Paul.Zimmermann@inria.fr> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
* Always define __USE_TIME_BITS64 when 64 bit time_t is usedAdhemerval Zanella2024-04-022-0/+10
| | | | | | | | | | | | | | | | | | | | It was raised on libc-help [1] that some Linux kernel interfaces expect the libc to define __USE_TIME_BITS64 to indicate the time_t size for the kABI. Different than defined by the initial y2038 design document [2], the __USE_TIME_BITS64 is only defined for ABIs that support more than one time_t size (by defining the _TIME_BITS for each module). The 64 bit time_t redirects are now enabled using a different internal define (__USE_TIME64_REDIRECTS). There is no expected change in semantic or code generation. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and arm-linux-gnueabi [1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html [2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Reviewed-by: DJ Delorie <dj@redhat.com>
* manual/tunables - Add entry for enable_secure tunable.Joe Talbott2024-03-011-0/+10
|
* trivial doc fix: remove weird phrase "syscall takes zero to five arguments"Askar Safin2024-02-141-2/+1
| | | | | | | | | | | | | "number of arguments, from zero to five" is wrong, because on Linux maximal number of arguments is 6, not 5. Also, maximal number of arguments is kernel-dependent, so let's not include it here at all. Moreover, "Each kind of system call has a definite number of arguments" is questionable. Think about SYS_open on Linux, which takes 2 or 3 arguments. Or SYS_clone on Linux x86_64, which takes 2 to 5 arguments. So I propose to fully remove this sentence. Signed-off-by: Askar Safin <safinaskar@zohomail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: fix qsort example in manualPaul Eggert2024-02-011-9/+12
| | | | | | | | * manual/search.texi (Comparison Functions, Array Sort Function): Sort an array of long ints, not doubles, to avoid hassles with NaNs. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* manual: Fix up stdbit.texiJakub Jelinek2024-02-011-1/+1
| | | | | | My recent change broke make pdf and in other documentation formats results in weird rendering and invalid URL, all because of a forgotten comma to separate @uref arguments.
* Refer to C23 in place of C2X in glibcJoseph Myers2024-02-015-42/+42
| | | | | | | | | | | | | | | WG14 decided to use the name C23 as the informal name of the next revision of the C standard (notwithstanding the publication date in 2024). Update references to C2X in glibc to use the C23 name. This is intended to update everything *except* where it involves renaming files (the changes involving renaming tests are intended to be done separately). In the case of the _ISOC2X_SOURCE feature test macro - the only user-visible interface involved - support for that macro is kept for backwards compatibility, while adding _ISOC23_SOURCE. Tested for x86_64.
* Use gcc __builtin_stdc_* builtins in stdbit.h if possibleJakub Jelinek2024-01-311-1/+7
| | | | | | | | | | | | | | | | | The following patch uses the GCC 14 __builtin_stdc_* builtins in stdbit.h for the type-generic macros, so that when compiled with GCC 14 or later, it supports not just 8/16/32/64-bit unsigned integers, but also 128-bit (if target supports them) and unsigned _BitInt (any supported precision). And so that the macros don't expand arguments multiple times and can be evaluated in constant expressions. The new testcase is gcc's gcc/testsuite/gcc.dg/builtin-stdc-bit-1.c adjusted to test stdbit.h and the type-generic macros in there instead of the builtins and adjusted to use glibc test framework rather than gcc style tests with __builtin_abort (). Signed-off-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Joseph Myers <josmyers@redhat.com>
* INSTALL, install.texi: minor updates, regenerateAndreas K. Hüttel2024-01-311-3/+3
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* contrib.texi: updateAndreas K. Hüttel2024-01-301-8/+24
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* manual/io: Fix swapped reading and writing phrase.Joe Simmons-Talbott2024-01-301-1/+1
| | | | Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* manual: fix order of arguments of memalign and aligned_alloc (Bug 27547)Dennis Brendel2024-01-241-2/+2
| | | | | | | On the summary page the order of the function arguments was reversed, but it is in correct order in the other places of the manual. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* manual, NEWS: Document malloc side effect of dynamic TLS changesFlorian Weimer2024-01-241-0/+8
| | | | | | | | The increased malloc subsystem usage is a side effect of commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls access after dlopen [BZ #19924]"). Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* stdlib: Reinstate stable mergesort implementation on qsortAdhemerval Zanella2024-01-153-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mergesort removal from qsort implementation (commit 03bf8357e8) had the side-effect of making sorting nonstable. Although neither POSIX nor C standard specify that qsort should be stable, it seems that it has become an instance of Hyrum's law where multiple programs expect it. Also, the resulting introsort implementation is not faster than the previous mergesort (which makes the change even less appealing). This patch restores the previous mergesort implementation, with the exception of machinery that checks the resulting allocation against the _SC_PHYS_PAGES (it only adds complexity and the heuristic not always make sense depending on the system configuration and load). The alloca usage was replaced with a fixed-size buffer. For the fallback mechanism, the implementation uses heapsort. It is simpler than quicksort, and it does not suffer from adversarial inputs. With memory overcommit, it should be rarely triggered. The drawback is mergesort requires O(n) extra space, and since it is allocated with malloc the function is AS-signal-unsafe. It should be feasible to change it to use mmap, although I am not sure how urgent it is. The heapsort is also nonstable, so programs that require a stable sort would still be subject to this latent issue. The tst-qsort5 is removed since it will not create quicksort adversarial inputs with the current qsort_r implementation. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* i386: Fail if configured with --enable-cetAdhemerval Zanella2024-01-091-2/+1
| | | | | | Since it is only supported for x86_64. Checked on i686-linux-gnu.
* Remove ia64-linux-gnuAdhemerval Zanella2024-01-082-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 6.7 removed ia64 from the official tree [1], following the general principle that a glibc port needs upstream support for the architecture in all the components it depends on (binutils, GCC, and the Linux kernel). Apart from the removal of sysdeps/ia64 and sysdeps/unix/sysv/linux/ia64, there are updates to various comments referencing ia64 for which removal of those references seemed appropriate. The configuration is removed from README and build-many-glibcs.py. The CONTRIBUTED-BY, elf/elf.h, manual/contrib.texi (the porting mention), *.po files, config.guess, and longlong.h are not changed. For Linux it allows cleanup some clone2 support on multiple files. The following bug can be closed as WONTFIX: BZ 22634 [2], BZ 14250 [3], BZ 21634 [4], BZ 10163 [5], BZ 16401 [6], and BZ 11585 [7]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ff221426d33db909f7159fdf620c3b052e2d1c [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22634 [3] https://sourceware.org/bugzilla/show_bug.cgi?id=14250 [4] https://sourceware.org/bugzilla/show_bug.cgi?id=21634 [5] https://sourceware.org/bugzilla/show_bug.cgi?id=10163 [6] https://sourceware.org/bugzilla/show_bug.cgi?id=16401 [7] https://sourceware.org/bugzilla/show_bug.cgi?id=11585 Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* elf: Add ELF_DYNAMIC_AFTER_RELOC to rewrite PLTH.J. Lu2024-01-051-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add ELF_DYNAMIC_AFTER_RELOC to allow target specific processing after relocation. For x86-64, add #define DT_X86_64_PLT (DT_LOPROC + 0) #define DT_X86_64_PLTSZ (DT_LOPROC + 1) #define DT_X86_64_PLTENT (DT_LOPROC + 3) 1. DT_X86_64_PLT: The address of the procedure linkage table. 2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage table. 3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table entry. With the r_addend field of the R_X86_64_JUMP_SLOT relocation set to the memory offset of the indirect branch instruction. Define ELF_DYNAMIC_AFTER_RELOC for x86-64 to rewrite the PLT section with direct branch after relocation when the lazy binding is disabled. PLT rewrite is disabled by default since SELinux may disallow modifying code pages and ld.so can't detect it in all cases. Use $ export GLIBC_TUNABLES=glibc.cpu.plt_rewrite=1 to enable PLT rewrite with 32-bit direct jump at run-time or $ export GLIBC_TUNABLES=glibc.cpu.plt_rewrite=2 to enable PLT rewrite with 32-bit direct jump and on APX processors with 64-bit absolute jump at run-time. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* i386: Ignore --enable-cetH.J. Lu2024-01-041-7/+4
| | | | | | | | | | | | | | Since shadow stack is only supported for x86-64, ignore --enable-cet for i386. Always setting $(enable-cet) for i386 to "no" to support ifneq ($(enable-cet),no) in x86 Makefiles. We can't use ifeq ($(enable-cet),yes) since $(enable-cet) can be "yes", "no" or "permissive". Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Implement C23 <stdbit.h>Joseph Myers2024-01-034-3/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds a header <stdbit.h> with various functions and type-generic macros for bit-manipulation of unsigned integers (plus macro defines related to endianness). Implement this header for glibc. The functions have both inline definitions in the header (referenced by macros defined in the header) and copies with external linkage in the library (which are implemented in terms of those macros to avoid duplication). They are documented in the glibc manual. Tests, as well as verifying results for various inputs (of both the macros and the out-of-line functions), verify the types of those results (which showed up a bug in an earlier version with the type-generic macro stdc_has_single_bit wrongly returning a promoted type), that the macros can be used at top level in a source file (so don't use ({})), that they evaluate their arguments exactly once, and that the macros for the type-specific functions have the expected implicit conversions to the relevant argument type. Jakub previously referred to -Wconversion warnings in type-generic macros, so I've included a test with -Wconversion (but the only warnings I saw and fixed from that test were actually in inline functions in the <stdbit.h> header - not anything coming from use of the type-generic macros themselves). This implementation of the type-generic macros does not handle unsigned __int128, or unsigned _BitInt types with a width other than that of a standard integer type (and C23 doesn't require the header to handle such types either). Support for those types, using the new type-generic built-in functions Jakub's added for GCC 14, can reasonably be added in a followup (along of course with associated tests). This implementation doesn't do anything special to handle C++, or have any tests of functionality in C++ beyond the existing tests that all headers can be compiled in C++ code; it's not clear exactly what form this header should take in C++, but probably not one using macros. DIS ballot comment AT-107 asks for the word "count" to be added to the names of the stdc_leading_zeros, stdc_leading_ones, stdc_trailing_zeros and stdc_trailing_ones functions and macros. I don't think it's likely to be accepted (accepting any technical comments would mean having an FDIS ballot), but if it is accepted at the WG14 meeting (22-26 January in Strasbourg, starting with DIS ballot comment handling) then there would still be time to update glibc for the renaming before the 2.39 release. The new functions and header are placed in the stdlib/ directory in glibc, rather than creating a new toplevel stdbit/ or putting them in string/ alongside ffs. Tested for x86_64 and x86.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-0147-47/+47
|
* manual: Clarify undefined behavior of feenableexcept (BZ 31019)Bruno Haible2023-12-191-0/+6
| | | | | | Explain undefined behavior of feenableexcept in a special case. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* elf: Ignore GLIBC_TUNABLES for setuid/setgid binariesAdhemerval Zanella2023-11-211-9/+0
| | | | | | | | | | | | | | | | | | | | The tunable privilege levels were a retrofit to try and keep the malloc tunable environment variables' behavior unchanged across security boundaries. However, CVE-2023-4911 shows how tricky can be tunable parsing in a security-sensitive environment. Not only parsing, but the malloc tunable essentially changes some semantics on setuid/setgid processes. Although it is not a direct security issue, allowing users to change setuid/setgid semantics is not a good security practice, and requires extra code and analysis to check if each tunable is safe to use on all security boundaries. It also means that security opt-in features, like aarch64 MTE, would need to be explicit enabled by an administrator with a wrapper script or with a possible future system-wide tunable setting. Co-authored-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com>
* elf: Remove /etc/suid-debug supportAdhemerval Zanella2023-11-212-6/+2
| | | | | | | | | | | | | | | | Since malloc debug support moved to a different library (libc_malloc_debug.so), the glibc.malloc.check requires preloading the debug library to enable it. It means that suid-debug support has not been working since 2.34. To restore its support, it would require to add additional information and parsing to where to find libc_malloc_debug.so. It is one thing less that might change AT_SECURE binaries' behavior due to environment configurations. Checked on x86_64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* manual: Fix termios.c example. (Bug 31078)Carlos O'Donell2023-11-201-2/+1
| | | | | | | | | | | | Remove the unused 'char *name;' from the example. Use write instead of putchar to write input as it is read. Example tested on x86_64 by compiling and running the example. Tested by building the manual pdf and reviewing the results. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* AArch64: Remove Falkor memcpyWilco Dijkstra2023-11-131-1/+1
| | | | | | | | | | The latest implementations of memcpy are actually faster than the Falkor implementations [1], so remove the falkor/phecda ifuncs for memcpy and the now unused IS_FALKOR/IS_PHECDA defines. [1] https://sourceware.org/pipermail/libc-alpha/2022-December/144227.html Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Fix type typo in “String/Array Conventions” docPaul Eggert2023-11-081-1/+1
| | | | | | * manual/string.texi (String/Array Conventions): Fix typo reported by Alejandro Colomar <alx@kernel.org> in: https://sourceware.org/pipermail/libc-alpha/2023-November/152646.html
* elf: Add glibc.mem.decorate_maps tunableAdhemerval Zanella2023-11-071-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PR_SET_VMA_ANON_NAME support is only enabled through a configurable kernel switch, mainly because assigning a name to a anonymous virtual memory area might prevent that area from being merged with adjacent virtual memory areas. For instance, with the following code: void *p1 = mmap (NULL, 1024 * 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); void *p2 = mmap (p1 + (1024 * 4096), 1024 * 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); The kernel will potentially merge both mappings resulting in only one segment of size 0x800000. If the segment is names with PR_SET_VMA_ANON_NAME with different names, it results in two mappings. Although this will unlikely be an issue for pthread stacks and malloc arenas (since for pthread stacks the guard page will result in a PROT_NONE segment, similar to the alignment requirement for the arena block), it still might prevent the mmap memory allocated for detail malloc. There is also another potential scalability issue, where the prctl requires to take the mmap global lock which is still not fully fixed in Linux [1] (for pthread stacks and arenas, it is mitigated by the stack cached and the arena reuse). So this patch disables anonymous mapping annotations as default and add a new tunable, glibc.mem.decorate_maps, can be used to enable it. [1] https://lwn.net/Articles/906852/ Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: DJ Delorie <dj@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-29 08:18:48 +0000