about summary refs log tree commit diff
path: root/manual
Commit message (Collapse)AuthorAgeFilesLines
* Linux: Make __rseq_size useful for feature detection (bug 31965)Florian Weimer2024-07-161-2/+6
| | | | | | | | | | | | The __rseq_size value is now the active area of struct rseq (so 20 initially), not the full struct size including padding at the end (32 initially). Update misc/tst-rseq to print some additional diagnostics. Reviewed-by: Michael Jeanson <mjeanson@efficios.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> (cherry picked from commit 2e456ccf0c34a056e3ccafac4a0c7effef14d918)
* misc: Add support for Linux uio.h RWF_NOAPPEND flagStafford Horne2024-05-291-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> (cherry picked from commit 3db9d208dd5f30b12900989c6d2214782b8e2011)
* Always define __USE_TIME_BITS64 when 64 bit time_t is usedAdhemerval Zanella2024-05-282-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> (cherry picked from commit a4ed0471d71739928a0d0fa3258b3ff3b158e9b9)
* Use gcc __builtin_stdc_* builtins in stdbit.h if possibleJakub Jelinek2024-03-041-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> (cherry picked from commit da89496337b97e6a2aaf1e81d55cf998f6db1070)
* 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>
* stdlib: Remove use of mergesort on qsort (BZ 21719)Adhemerval Zanella2023-10-313-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the mergesort optimization on qsort implementation and uses the introsort instead. The mergesort implementation has some issues: - It is as-safe only for certain types sizes (if total size is less than 1 KB with large element sizes also forcing memory allocation) which contradicts the function documentation. Although not required by the C standard, it is preferable and doable to have an O(1) space implementation. - The malloc for certain element size and element number adds arbitrary latency (might even be worse if malloc is interposed). - To avoid trigger swap from memory allocation the implementation relies on system information that might be virtualized (for instance VMs with overcommit memory) which might lead to potentially use of swap even if system advertise more memory than actually has. The check also have the downside of issuing syscalls where none is expected (although only once per execution). - The mergesort is suboptimal on an already sorted array (BZ#21719). The introsort implementation is already optimized to use constant extra space (due to the limit of total number of elements from maximum VM size) and thus can be used to avoid the malloc usage issues. Resulting performance is slower due the usage of qsort, specially in the worst-case scenario (partialy or sorted arrays) and due the fact mergesort uses a slight improved swap operations. This change also renders the BZ#21719 fix unrequired (since it is meant to fix the sorted input performance degradation for mergesort). The manual is also updated to indicate the function is now async-cancel safe. Checked on x86_64-linux-gnu. Reviewed-by: Noah Goldstein <goldstein.w.n@gmail.com>
* crypt: Remove manul entry for --enable-cryptAdhemerval Zanella2023-10-311-13/+0
|
* crypt: Remove libcrypt supportAdhemerval Zanella2023-10-305-341/+25
| | | | | | | | | | | | | | | | | | All the crypt related functions, cryptographic algorithms, and make requirements are removed, with only the exception of md5 implementation which is moved to locale folder since it is required by localedef for integrity protection (libc's locale-reading code does not check these, but localedef does generate them). Besides thec code itself, both internal documentation and the manual is also adjusted. This allows to remove both --enable-crypt and --enable-nss-crypt configure options. Checked with a build for all affected ABIs. Co-authored-by: Zack Weinberg <zack@owlfolio.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* x86: Add support for AVX10 preset and vec size in cpu-featuresNoah Goldstein2023-09-291-0/+12
| | | | | | | | | | | | This commit add support for the new AVX10 cpu features: https://cdrdv2-public.intel.com/784267/355989-intel-avx10-spec.pdf We add checks for: - `AVX10`: Check if AVX10 is present. - `AVX10_{X,Y,Z}MM`: Check if a given vec class has AVX10 support. `make check` passes and cpuid output was checked against GNR/DMR on an emulator.
* C2x scanf %wN, %wfN supportJoseph Myers2023-09-281-0/+14
| | | | | | | | | ISO C2x defines scanf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers, similar to the printf support previously added. Tested for x86_64 and x86.
* manual: Fix ld.so diagnostics menu/section structureFlorian Weimer2023-09-061-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | And shorten the section/node names a bit, so that the menu entries become easier to read. Texinfo 6.5 fails to process the previous structure: ./dynlink.texi:56: warning: node `Dynamic Linker Introspection' is next for `Dynamic Linker Diagnostics' in sectioning but not in menu ./dynlink.texi:56: warning: node up `Dynamic Linker Diagnostics' in menu `Dynamic Linker Invocation' and in sectioning `Dynamic Linker' differ ./dynlink.texi:1: node `Dynamic Linker' lacks menu item for `Dynamic Linker Diagnostics' despite being its Up target ./dynlink.texi:226: warning: node prev `Dynamic Linker Introspection' in menu `Dynamic Linker Invocation' and in sectioning `Dynamic Linker Diagnostics' differ Texinfo 7.0.2 does not report an error. This fixes commit f21962ddfc8bb23e92597da1f98e313dbde11cc1 ("manual: Document ld.so --list-diagnostics output"). Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
* linux: Add pidfd_getpidAdhemerval Zanella Netto2023-09-051-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | This interface allows to obtain the associated process ID from the process file descriptor. It is done by parsing the procps fdinfo information. Its prototype is: pid_t pidfd_getpid (int fd) It returns the associated pid or -1 in case of an error and sets the errno accordingly. The possible errno values are those from open, read, and close (used on procps parsing), along with: - EBADF if the FD is negative, does not have a PID associated, or if the fdinfo fields contain a value larger than pid_t. - EREMOTE if the PID is in a separate namespace. - ESRCH if the process is already terminated. Checked on x86_64-linux-gnu on Linux 4.15 (no CLONE_PIDFD or waitid support), Linux 5.4 (full support), and Linux 6.2. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* posix: Add pidfd_spawn and pidfd_spawnp (BZ 30349)Adhemerval Zanella Netto2023-09-051-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Returning a pidfd allows a process to keep a race-free handle for a child process, otherwise, the caller will need to either use pidfd_open (which still might be subject to TOCTOU) or keep the old racy interface base on pid_t. To correct use pifd_spawn, the kernel must support not only returning the pidfd with clone/clone3 but also waitid (P_PIDFD) (added on Linux 5.4). If kernel does not support the waitid, pidfd return ENOSYS. It avoids the need to racy workarounds, such as reading the procfs fdinfo to get the pid to use along with other wait interfaces. These interfaces are similar to the posix_spawn and posix_spawnp, with the only difference being it returns a process file descriptor (int) instead of a process ID (pid_t). Their prototypes are: int pidfd_spawn (int *restrict pidfd, const char *restrict file, const posix_spawn_file_actions_t *restrict facts, const posix_spawnattr_t *restrict attrp, char *const argv[restrict], char *const envp[restrict]) int pidfd_spawnp (int *restrict pidfd, const char *restrict path, const posix_spawn_file_actions_t *restrict facts, const posix_spawnattr_t *restrict attrp, char *const argv[restrict_arr], char *const envp[restrict_arr]); A new symbol is used instead of a posix_spawn extension to avoid possible issues with language bindings that might track the return argument lifetime. Although on Linux pid_t and int are interchangeable, POSIX only states that pid_t should be a signed integer. Both symbols reuse the posix_spawn posix_spawn_file_actions_t and posix_spawnattr_t, to void rehash posix_spawn API or add a new one. It also means that both interfaces support the same attribute and file actions, and a new flag or file action on posix_spawn is also added automatically for pidfd_spawn. Also, using posix_spawn plumbing allows the reusing of most of the current testing with some changes: - waitid is used instead of waitpid since it is a more generic interface. - tst-posix_spawn-setsid.c is adapted to take into consideration that the caller can check for session id directly. The test now spawns itself and writes the session id as a file instead. - tst-spawn3.c need to know where pidfd_spawn is used so it keeps an extra file description unused. Checked on x86_64-linux-gnu on Linux 4.15 (no CLONE_PIDFD or waitid support), Linux 5.4 (full support), and Linux 6.2. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* elf: Check that --list-diagnostics output has the expected syntaxFlorian Weimer2023-08-251-0/+8
| | | | | | | | | | Parts of elf/tst-rtld-list-diagnostics.py have been copied from scripts/tst-ld-trace.py. The abnf module is entirely optional and used to verify the ABNF grammar as included in the manual. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* manual: Document ld.so --list-diagnostics outputFlorian Weimer2023-08-251-0/+207
| | | | Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* manual/jobs.texi: Add missing @item EPERM for getpgidMark Wielaard2023-08-251-0/+1
| | | | | | | The missing @item makes it look like errno will be set to ESRCH if a cross-session getpgid is not permitted. Found by ulfvonbelow on irc.
* PowerPC: Influence cpu/arch hwcap features via GLIBC_TUNABLESMahesh Bodapati2023-08-011-1/+4
| | | | | | | | | | | This patch enables the option to influence hwcaps used by PowerPC. The environment variable, GLIBC_TUNABLES=glibc.cpu.hwcaps=-xxx,yyy,-zzz...., can be used to enable CPU/ARCH feature yyy, disable CPU/ARCH feature xxx and zzz, where the feature name is case-sensitive and has to match the ones mentioned in the file{sysdeps/powerpc/dl-procinfo.c}. Note that the hwcap tunables only used in the IFUNC selection. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* install.texi: Build was tested with binutils 2.41 (just released)Andreas K. Hüttel2023-07-301-1/+1
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* install.texi: Update versions of most recent build toolsAndreas K. Hüttel2023-07-271-7/+7
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* contrib.texi: Update for 2.38Andreas K. Hüttel2023-07-271-7/+103
| | | | Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* <sys/platform/x86.h>: Add APX supportH.J. Lu2023-07-271-0/+3
| | | | | | | | Add support for Intel Advanced Performance Extensions: https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html to <sys/platform/x86.h>.
* configure: Disable building libcrypt by defaultSiddhesh Poyarekar2023-07-201-10/+12
| | | | | | | | | | | | We mentioned eventual dropping of libcrypt in the 2.28 NEWS. Actually put that plan in motion by first disabling building libcrypt by default. note in NEWS that the library will be dropped completely in a future release. Also add a couple of builds into build-many-glibcs.py. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
* configure: Use autoconf 2.71Siddhesh Poyarekar2023-07-171-1/+1
| | | | | | | | | | | | | | Bump autoconf requirement to 2.71 to allow regenerating configure on more recent distributions. autoconf 2.71 has been in Fedora since F36 and is the current version in Debian stable (bookworm). It appears to be current in Gentoo as well. All sysdeps configure and preconfigure scripts have also been regenerated; all changes are trivial transformations that do not affect functionality. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* manual: Fix typos in struct dl_find_objectBert Wesarg2023-07-131-2/+2
| | | | | Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Allow glibc to be built with _FORTIFY_SOURCEFrédéric Bérat2023-07-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add --enable-fortify-source option. It is now possible to enable fortification through a configure option. The level may be given as parameter, if none is provided, the configure script will determine what is the highest level possible that can be set considering GCC built-ins availability and set it. If level is explicitly set to 3, configure checks if the compiler supports the built-in function necessary for it or raise an error if it isn't. If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is forcibly undefined (and therefore disabled). The result of the configure checks are new variables, ${fortify_source} and ${no_fortify_source} that can be used to appropriately populate CFLAGS. A dedicated patch will follow to make use of this variable in Makefiles when necessary. Updated NEWS and INSTALL. Adding dedicated x86_64 variant that enables the configuration. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* manual: Update documentation of strerror and related functionsFlorian Weimer2023-07-031-26/+98
| | | | | | | | | | | | The current implementation of strerror is thread-safe, but this has implications for the lifetime of the return string. Describe the strerror_l function. Describe both variants of the strerror_r function. Mention the lifetime of the returned string for strerrorname_np and strerrordesc_np. Clarify that perror output depends on the current locale. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* manual: Enhance documentation of the <ctype.h> functionsFlorian Weimer2023-07-031-8/+24
| | | | | | | | Describe the problems with signed characters, and the glibc extension to deal with most of them. Mention that the is* functions return zero for the special argument EOF. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Call "CST" a time zone abbreviation, not a namePaul Eggert2023-06-222-12/+12
| | | | | | In documentation, call strings like "CST" time zone abbreviations, not time zone names. This terminology is more precise, and is what tzdb uses. A string like "CST" is ambiguous and does not fully name a time zone.
* C2x scanf %b supportJoseph Myers2023-06-191-3/+9
| | | | | | | | | | | | ISO C2x defines scanf %b for input of binary integers (with an optional 0b or 0B prefix). Implement such support, along with the corresponding SCNb* macros in <inttypes.h>. Unlike the support for binary integers with 0b or 0B prefix with scanf %i, this is supported in all versions of scanf (independent of the standards mode used for compilation), because there are no backwards compatibility concerns (%b wasn't previously a supported format) the way there were for %i. Tested for x86_64 and x86.
* C2x printf %wN, %wfN support (bug 24466)Joseph Myers2023-06-191-0/+18
| | | | | | | | | | | | | | | | | | ISO C2x defines printf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers (such a feature was previously requested in bug 24466). scanf support is to be added separately. GCC 13 has format checking support for these modifiers. When used with the support for registering format specifiers, these modifiers are translated to existing flags in struct printf_info, rather than trying to add some way of distinguishing them without breaking the printf_info ABI. C2x requires an error to be returned for unsupported values of N; this is implemented for printf-family functions, but the parse_printf_format interface doesn't support error returns, so such an error gets discarded by that function. Tested for x86_64 and x86.
* manual: Manual update for strlcat, strlcpy, wcslcat, wclscpyPaul Eggert2023-06-142-3/+101
| | | | | Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* Fix misspellings in manual/ -- BZ 25337Paul Pluzhnikov2023-05-2713-15/+15
|
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-08 11:56:35 +0000