packaging: Switch off ASan

Change-Id: I38e228d0389905dac11a300295cfc32df0cfe112
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

packaging: add license files to all sub components

The license files are added to only library components because they could be
included to target binary.

Change-Id: I7cb352ba1457709ba440b1a926056f1b1d74bd3e
Signed-off-by: Chan Lee <chan45.lee@samsung.com>
Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

packaging: provide 64bit libs on 32bit build env

In some cases, especially .Net toolchain needs 64bit libs to execute
even though 32bit build environment.
It's a little weird but possble because almost archtecture of build machine is 64bit.

Change-Id: I0582231028edf64b0cb8e751ec3aba3ccb8e0e0e
Signed-off-by: Chan Lee <chan45.lee@samsung.com>

Lie about futex_atomic_cmpxchg_inatomic kernel support.

In past versions of glibc, we incorrectly assumed all ARM kernels
in all configurations supported futex_atomic_cmpxchg_inatomic. This
was clearly a lie, however it was a lie that we relied on, because
the fallback implementation appears to not play nicely with certain
applications like pulseaudio.  Restore the lie for kernels > 2.6.32
and plug our ears and scream "LA LA LA" about how wrong this is.

Author: Adam Conrad <adconrad@ubuntu.com>
Bug-Ubuntu: https://launchpad.net/bugs/1436162
Last-Update: 2015-03-25

Change-Id: I9d9ceffd5dd2d2f37e45b282317febfb6524b4a8
Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

packaging: Enable memcpy in sysdeps/arm/memcpy.S for ARM

Enable memcpy in sysdeps/arm/memcpy.S for ARM
instead of memcpy in sysdeps/arm/armv7/multiarch/

Turn on --disable-multi-arch option for configure except %{ix86} x86_64 arch.

(port from tizen_3.0_base:3a309608ceb25843584b0a2c9075c16a1b892e86)

Change-Id: Ia22d4cd3821fea2a7ea0ef2179fc0b4f6e6ef3e9
Signed-off-by: Pavel Kopyl <p.kopyl@samsung.com>

Nss configuration update

During user switch we must set up groups related with privileges
owned by user. The list of groups is taken from security-manager
service.

Change-Id: I3b01aad84880328e51eccf6ed12f4082f5b639cc

packaging: renamed linaro-glibc.spec -> glibc.spec

Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

packaging: remove fno-omit-frame-pointer from optflags

fix error: bp cannot be used in asm here
(under ../sysdeps/unix/sysv/linux/posix_fallocate.c:39:1)

Signed-off-by: Ivan Baravy <i.baravy@samsung.com>
Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

packaging: disabled libmvec library.

Libmvec is vector math library added in Glibc 2.22.

Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

packaging: fix build error

'bits/stdio-lock.h': No such file or directory

Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

packaging: add packaging

Signed-off-by: Dongkyun, Son <dongkyun.s@samsung.com>

Create ChangeLog.old/ChangeLog.26.

Prepare for glibc 2.37 release.

Update version.h, and include/features.h.

x86: Fix strncat-avx2.S reading past length [BZ #30065]

Occurs when `src` has no null-term.

Two cases:

1) Zero-length check is doing:
```
    test    %rdx, %rdx
    jl      L(zero_len)
```
which doesn't actually check zero (was at some point `decq` and the
flag never got updated).

The fix is just make the flag `jle` i.e:
```
    test    %rdx, %rdx
    jle     L(zero_len)
```

2) Length check in page-cross case checking if we should continue is
doing:
```
    cmpq    %r8, %rdx
    jb      L(page_cross_small)
```
which means we will continue searching for null-term if length ends at
the end of a page and there was no null-term in `src`.

The fix is to make the flag:
```
    cmpq    %r8, %rdx
    jbe     L(page_cross_small)
```

Update install.texi, and regenerate INSTALL.

Update manual/contrib.texi.

Thank Yinyu Cai for their maintainership of the LoongArch port.

Thank Vineet Gupta for their maintainership of the ARC port.

Thank Tulio Magno Quites Machado Filho for their past maintainership
of the PowerPC port.

Thank Rajalakshmi Srinivasaraghavan for their current maintainership
of the PowerPC port.

Update NEWS file with bug fixes.

Regenerate configure.

Run using vanilla upstream autoconf 2.69.

Minor whitespace change to sysdeps/loongarch/configure and
sysdeps/mach/configure, and nothing else.

Update all PO files in preparation for release.

doc: correct _FORTIFY_SOURCE doc in features.h

libio: Update number of written bytes in dprintf implementation

The __printf_buffer_flush_dprintf function needs to record that
the buffer has been written before reusing it.  Without this
accounting, dprintf always returns zero.

Fixes commit 8ece45e4f586abd212d1c02d74d38ef681a45600
("libio: Convert __vdprintf_internal to buffers").

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>

Account for octal marker in %#o format

Use binutils 2.40 branch in build-many-glibcs.py

This patch makes build-many-glibcs.py use binutils 2.40 branch.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).

Use MPFR 4.2.0, MPC 1.3.1 in build-many-glibcs.py

This patch makes build-many-glibcs.py use the new MPFR 4.2.0 and MPC
1.3.1 releases.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).

stdio-common: Handle -1 buffer size in __sprintf_chk & co (bug 30039)

This shows up as an assertion failure when sprintf is called with
a specifier like "%.8g" and libquadmath is linked in:

Fatal glibc error: printf_buffer_as_file.c:31
  (__printf_buffer_as_file_commit): assertion failed:
  file->stream._IO_write_ptr <= file->next->write_end

Fix this by detecting pointer wraparound in __vsprintf_internal
and saturate the addition to the end of the address space instead.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>

Document '%F' format specifier

The '%F' format specifier was implemented in commit 6c46718f9f0 on
2000-08-23, but remains undocumented in the manual.
https://stackoverflow.com/questions/75157669/format-specifier-f-missing-from-glibcs-documentation

Fix that.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>

sparc (64bit): Regenerate ulps

Linux catbus 5.15.69-gentoo #1 SMP Sat Sep 24 07:56:24 PDT 2022 sparc64 sun4v UltraSparc T5 (Niagara5) GNU/Linux
gcc (Gentoo 11.3.1_p20221209 p3) 11.3.1 20221209
GNU ld (Gentoo 2.38 p4) 2.38
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

ia64: Regenerate ulps

Linux guppy 5.13.0-00002-gdecb01746d6c #368 SMP Sat Aug 14 20:10:13 UTC 2021 ia64 Dual-Core Intel(R) Itanium(R) Processor 9040 GenuineIntel GNU/Linux
gcc (Gentoo 12.2.1_p20221231 p8) 12.2.1 20221231
GNU ld (Gentoo 2.40 p1) 2.40
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

Update libc.pot for 2.37 release.

x86: Cache computation for AMD architecture.

All AMD architectures cache details will be computed based on
__cpuid__ `0x8000_001D` and the reference to __cpuid__ `0x8000_0006` will be
zeroed out for future architectures.

Reviewed-by: Premachandra Mallappa <premachandra.mallappa@amd.com>

manual: Fix typo

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Add STATX_DIOALIGN from Linux 6.1 to bits/statx-generic.h

Linux 6.1 adds a new STATX_DIOALIGN constant.  Add it to glibc's
bits/statx-generic.h.

Tested for x86_64.

Add IPPROTO_L2TP from Linux 6.1 to netinet/in.h

Linux 6.1 adds a define IPPROTO_L2TP to its include/uapi/linux/in.h
(not strictly a new constant, since it's moved from
include/uapi/linux/l2tp.h).  Add this constant to glibc's
netinet/in.h.

Tested for x86_64.

AArch64: Improve strrchr

Use shrn for narrowing the mask which simplifies code and speeds up small
strings.  Unroll the first search loop to improve performance on large
strings.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Optimize strnlen

Optimize strnlen using the shrn instruction and improve the main loop.
Small strings are around 10% faster, large strings are 40% faster on
modern CPUs.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Optimize strlen

Optimize strlen by unrolling the main loop.  Large strings are 64% faster on
modern CPUs.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Optimize strcpy

Unroll the main loop.  Large strings are around 20% faster on modern CPUs.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Improve strchrnul

Unroll the main loop, which improves performance slightly.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Optimize strchr

Simplify calculation of the mask using shrn.  Unroll the main loop.
Small strings are 20% faster on modern CPUs.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Improve strlen_asimd

Use shrn for the mask, merge tst+bne into cbnz, and tweak code alignment.
Performance improves slightly as a result.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Optimize memrchr

Optimize the main loop - large strings are 43% faster on modern CPUs.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

AArch64: Optimize memchr

Optimize the main loop - large strings are 40% faster on modern CPUs.

Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

hurd: Fix _NOFLSH value

shifting 1 (thus an integer) left 31 bit is undefined behavior. We have to
make it an unsigned integer to properly get 0x80000000 (like done in other
places).

elf: Fix GL(dl_phdr) and GL(dl_phnum) for static builds [BZ #29864]

The 73fc4e28b9464f0e refactor did not add the GL(dl_phdr) and
GL(dl_phnum) for static build, relying on the __ehdr_start symbol,
which is always added by the static linker, to get the correct values.

This is problematic in some ways:

  - The segment may see its in-memory size differ from its in-file
    size (or the binary may have holes).  The Linux has fixed is to
    provide concise values for both AT_PHDR and AT_PHNUM (commit
    0da1d5002745c - "fs/binfmt_elf: Fix AT_PHDR for unusual ELF files")

  - Some archs (alpha for instance) the hidden weak reference is not
    correctly pulled by the static linker and  __ehdr_start address
    end up being 0, which makes GL(dl_phdr) and GL(dl_phnum) have both
    invalid values (and triggering a segfault later on libc.so while
    accessing TLS variables).

The safer fix is to just restore the previous behavior to setup
GL(dl_phdr) and GL(dl_phnum) for static based on kernel auxv.  The
__ehdr_start fallback can also be simplified by not assuming weak
linkage (as for PIE).

The libc-static.c auxv init logic is moved to dl-support.c, since
the later is build without SHARED and then GLRO macro is defined
to access the variables directly.

The _dl_phdr is also assumed to be always non NULL, since an invalid
NULL values does not trigger TLS initialization (which is used in
various libc systems).

Checked on aarch64-linux-gnu, x86_64-linux-gnu, and i686-linux-gnu.

Reviewed-by: Florian Weimer <fweimer@redhat.com>

string: Suppress -Wmaybe-unitialized for wordcopy [BZ #19444]

When compiling with GCC 6+ the sparc build warns that some variables
might be used uninitialized.  However it does not seem the fact, since
the variables are really initialized (and also other targets that use the
same code, like powerpc, do not warn about it).

So suppress the warning for now.

Changes from v1:
* Update patch description and the explanation for the suppresion.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

scripts/build-many-glibcs.py: Remove unused RANLIB and STRIP option

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

configure: Move nm, objdump, and readelf to LIBC_PROG_BINUTILS

Allow the variables to be overriden or have the defaults come
from the compiler currently in use.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

configure: Allow user override LD, AR, OBJCOPY, and GPROF

The only way to override LD, AR, OBJCOPY, and GPROF is through
--with-binutils (setting the environments variables on configure is
overridden by LIBC_PROG_BINUTILS).

The build-many-glibcs.py (bmg) glibcs option generates a working config,
but not fully concise (some tools will be set from environment variable,
while other will be set from $CC --print-prog-name).  So remove the
environment variable set to always use the "$CC --print-prog-name".
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

math: Suppress -O0 warnings for soft-fp fsqrt [BZ #19444]

The patch suppress the same warnings from 87c266d758d29e52bfb717f90,
that shows issues for microblaze, mips soft-fp, nios2, and or1k.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

sunrpc: Suppress GCC -O1 warning on user2netname [BZ #19444]

The same issue described by 6128e82ebe973163d2dd614d31753c88c0c4d645
also happend with -O1.

Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

locale: Use correct buffer size for utf8_sequence_error [BZ #19444]

The buffer used by snprintf might not be large enough for all possible
inputs, as indicated by gcc with -O1:

../locale/programs/linereader.c: In function ‘utf8_sequence_error’:
../locale/programs/linereader.c:713:58: error: ‘%02x’ directive output
may be truncated writing between 2 and 8 bytes into a region of size
between 1 and 13 [-Werror=format-truncation=]
  713 |     snprintf (buf, sizeof (buf), "0x%02x 0x%02x 0x%02x 0x%02x",
      |                                                          ^~~~
../locale/programs/linereader.c:713:34: note: directive argument in the
range [0, 2147483647]
  713 |     snprintf (buf, sizeof (buf), "0x%02x 0x%02x 0x%02x 0x%02x",
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../locale/programs/linereader.c:713:5: note: ‘snprintf’ output between
20 and 38 bytes into a destination of size 30
  713 |     snprintf (buf, sizeof (buf), "0x%02x 0x%02x 0x%02x 0x%02x",
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  714 |               ch1, ch2, ch3, ch4);
      |               ~~~~~~~~~~~~~~~~~~~

Checked on x86_64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>

Add HWCAP2_SVE_EBF16 from Linux 6.1 to AArch64 bits/hwcap.h

Linux 6.1 adds a new AArch64 HWCAP2 value HWCAP2_SVE_EBF16; add it to
the corresponding bits/hwcap.h.

Tested with build-many-glibcs.py for aarch64.

Add _FORTIFY_SOURCE implementation documentation [BZ #28998]

There have been multiple requests to provide more detail on how the
_FORTIFY_SOURCE macro works, so this patch adds a new node in the
Library Maintenance section that does this.  A lot of the description is
implementation detail, which is why I put this in the appendix and not
in the main documentation.

Resolves: BZ #28998.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Florian Weimer <fweimer@redhat.com>

Update copyright dates not handled by scripts/update-copyrights

I've updated copyright dates in glibc for 2023.  This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.

Update copyright dates with scripts/update-copyrights

Remove trailing whitespace in gmp.h

Remove trailing whitespace

For some reason this causes a pre-commit check error for a copyright
date update commit, even though that commit doesn't touch anything
near the line with this whitespace.

C2x semantics for <tgmath.h>

<tgmath.h> implements semantics for integer generic arguments that
handle cases involving _FloatN / _FloatNx types as specified in TS
18661-3 plus some defect fixes.

C2x has further changes to the semantics for <tgmath.h> macros with
such types, which should also be considered defect fixes (although
handled through the integration of TS 18661-3 in C2x rather than
through an issue tracking process).  Specifically, the rules were
changed because of problems raised with using the macros with the
evaluation format types such as float_t and _Float32_t: the older
version of the rules didn't allow passing _FloatN / _FloatNx types to
the narrowing macros returning float or double, or passing float /
double / long double to the narrowing macros returning _FloatN /
_FloatNx, which was a problem with the evaluation format types which
could be either kind of type depending on the value of
FLT_EVAL_METHOD.

Thus the new rules allow cases of mixing types which were not allowed
before, and, as part of the changes, the handling of integer arguments
was also changed: if there is any _FloatNx generic argument, integer
generic arguments are treated as _Float32x (not double), while the
rule about treating integer arguments to narrowing macros returning
_FloatN or _FloatNx as _Float64 not double was removed (no longer
needed now double is a valid argument to such macros).

I've implemented the changes in GCC's __builtin_tgmath, which thus
requires updates to glibc's test expectations so that the tests
continue to build with GCC 13 (the test is also updated to test the
argument types that weren't allowed before but are now valid under C2x
rules).

Given those test changes, it's then also necessary to fix the
implementations in <tgmath.h> to have appropriate semantics with older
GCC so that the tests pass with GCC versions before GCC 13 as well.
For some cases (non-narrowing macros with two or three generic
arguments; narrowing macros returning _Float32x), the older version of
__builtin_tgmath doesn't correspond sufficiently well to C2x
semantics, so in those cases <tgmath.h> is adjusted to use the older
macro implementation instead of __builtin_tgmath.  The older macro
implementation is itself adjusted to give the desired semantics, with
GCC 7 and later.  (It's not possible to get the right semantics in all
cases for the narrowing macros with GCC 6 and before when the _FloatN
/ _FloatNx names are typedefs rather than distinct types.)

Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7,
11, 13; with execution of the math/tests for aarch64, arm, powerpc and
powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and
13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.

time: Set daylight to 1 for matching DST/offset change (bug 29951)

The daylight variable is supposed to be set to 1 if DST is ever in
use for the current time zone.  But __tzfile_read used to do this:

  __daylight = rule_stdoff != rule_dstoff;

This check can fail to set __daylight to 1 if the DST and non-DST
offsets happen to be the same.

Fix ldbl-128 built-in function use

Fix the following issues with built-in function use in
sysdeps/ieee754/ldbl-128 and sysdeps/ieee754/float128:

* fabsl used __builtin_fabsf128 unconditionally, breaking the build
  with GCC 6 for several architectures; it should use __builtin_fabsl
  with an appropriate redirection in float128_private.h.  (I'm not
  particularly concerned with building glibc with GCC 6; rather, I
  want to be able to run the tgmath.h tests with GCC 6, which is a
  significantly different case for tgmath.h compared to GCC 7 and
  later because of the lack of _FloatN / _FloatNx support in the
  compiler, and at present running the tests with a compiler means
  building glibc with that compiler.)

* Some (conditional) uses of built-in functions had been added to
  ldbl-128 without appropriate float128_private.h remapping (there was
  remapping for the macros controlling whether the built-in functions
  are used, just not for the functions themselves).

* s_llrintl.c called __builtin_round not __builtin_llrintl, which is
  obviously wrong.

Tested with build-many-glibcs.py for aarch64-linux-gnu, GCC 6 (where
it fixes the glibc build) and GCC 12, and with the glibc testsuite for
x86_64.

x86: Check minimum/maximum of non_temporal_threshold [BZ #29953]

The minimum non_temporal_threshold is 0x4040.  non_temporal_threshold may
be set to less than the minimum value when the shared cache size isn't
available (e.g., in an emulator) or by the tunable.  Add checks for
minimum and maximum of non_temporal_threshold.

This fixes BZ #29953.

i686: Regenerate ulps

Reviewed-by: Florian Weimer <fweimer@redhat.com>

hurd getcwd: Fix memory leak on error

hurd fcntl: Make LOCKED macro more robust

hurd: Make dl-sysdep __sbrk check __vm_allocate call

The caller won't be able to progress, but better crash than use random
addr.

htl: Drop duplicate check in __pthread_stack_alloc

hurd hurdstartup: Initialize remaining fields of hurd_startup_data

In case we don't have a bootstrap port or __exec_startup_get_info
failed, we should avoid leaking uninitialized fields of data.

hurd _S_msg_add_auth: Initialize new arrays to 0

If make_list fails, they would be undefined, and freeup with free
uninitialized pointers.

htl: Check error returned by __getrlimit

getdelim: ensure error indicator is set on error (bug 29917)

POSIX requires that getdelim and getline set the error indicator on the
stream when an error occured, in addition to setting errno.

htl: Fix sem_wait race between read and gsync_wait

If the value changes between sem_wait's read and the gsync_wait call,
the kernel will return KERN_INVALID_ARGUMENT, which we have to interpret
as the value having already changed.

This fixes applications (e.g. libgo) seeing sem_wait erroneously return
KERN_INVALID_ARGUMENT.

Avoid use of atoi in malloc

This patch is analogous to commit
a3708cf6b0a5a68e2ed1ce3db28a03ed21d368d2.

atoi has undefined behavior on out-of-range input, which makes it
problematic to use anywhere in glibc that might be processing input
out-of-range for atoi but not specified to produce undefined behavior
for the function calling atoi.  In conjunction with the C2x strtol
changes, use of atoi in libc can also result in localplt test failures
because the redirection for strtol does not interact properly with the
libc_hidden_proto call for __isoc23_strtol for the call in the inline
atoi implementation.

In malloc/arena.c, this issue shows up for atoi calls that are only
compiled for --disable-tunables (thus with the
x86_64-linux-gnu-minimal configuration of build-many-glibcs.py, for
example).  Change those atoi calls to use strtol directly, as in the
previous such changes.

Tested for x86_64 (--disable-tunables).

Linux: Pass size argument of epoll_create to the kernel

The kernel actually verifies it, and a garbage value in the register
causes improper system call failures.

Fixes commit c1c0dea38833751f36a145c32 ("Linux: Remove epoll_create,
inotify_init from syscalls.list") and commit d1d23b134244d59c4d6ef2295
("Lninux: consolidate epoll_create implementation").

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

Simplify scripts/cross-test-ssh.sh configuration.

With modern ssh clients and daemons it is required to use AcceptEnv and
SendEnv configuration options to correctly support testing the DSO sort
ordering tests.  This requirement is present because
scripts/dso-ordering-test.py injects GLIBC_TUNABLES to the left of the
${test_wrapper_env} and so it must both be sent by the ssh client and
accepted by the ssh daemon.  This requirement is removed in this change
and the injected GLIBC_TUNABLES is placed after ${run_program_env} and
so still correctly provides the override that the test requires.
This is similar to existing tests like elf/tst-pathopt.sh,
elf/tst-rtld-load-self.sh, and locale/tst-locale-locpath.sh.

Tested that it fixes two failures when cross-testing on aarch64 with
scripts/cross-test-ssh.sh and an ssh client and daemon that do not pass
GLIBC_TUNABLES. Without this fix such a configuration will report the
following failures (since the GLIBC_TUNABLES not preserved):
FAIL: elf/tst-bz15311
FAIL: elf/tst-bz28937

Tested without regression on native x86_64 and aarch64 builds.

Reviewed-by: Florian Weimer <fweimer@redhat.com>

Define MADV_COLLAPSE from Linux 6.1

Add the MADV_COLLAPSE constant from Linux 6.1 to bits/mman-linux.h and
the hppa bits/mman.h.

Tested for x86_64.

powerpc64: Increase SIGSTKSZ and MINSIGSTKSZ

This patch increases the value of SIGSTKSZ and MINSIGSTKSZ
for powerpc64 similar to the kernel commit
2f82ec19757f58549467db568c56e7dfff8af283 to allow
further expansion of the signal stack frame size.

Update all PO files in preparation for release.

Update kernel version to 6.1 in header constant tests

This patch updates the kernel version in the tests tst-mman-consts.py,
tst-mount-consts.py and tst-pidfd-consts.py to 6.1.  (There are no new
constants covered by these tests in 6.1 that need any other header
changes.)

Tested with build-many-glibcs.py.

Update syscall lists for Linux 6.1

Linux 6.1 has no new syscalls.  Update the version number in
syscall-names.list to reflect that it is still current for 6.1.

libio: Convert __vswprintf_internal to buffers (bug 27857)

Always null-terminate the buffer and set E2BIG if the buffer is too
small.  This fixes bug 27857.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

libio: Convert __obstack_vprintf_internal to buffers (bug 27124)

This fixes bug 27124 because the problematic built-in vtable is gone.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

libio: Convert __vdprintf_internal to buffers

The internal buffer size is set to 2048 bytes.  This is less than
the original BUFSIZ value used by buffered_vfprintf before
the conversion, but it hopefully covers all cases where write
boundaries matter.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

libio: Convert __vasprintf_internal to buffers

The buffer resizing algorithm is slightly different.  The initial
buffer is on the stack, and small buffers are directly allocated
on the heap using the exact required size.  The overhead of the
additional copy is compensated by the lowered setup cost for buffers
compared to libio streams.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

libio: Convert __vsprintf_internal to buffers

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

stdio-common: Add lock optimization to vfprintf and vfwprintf

After the rewrite and the implicit unbuffered streams handling, this
is very straightforward to add.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

stdio-common: Convert vfprintf and related functions to buffers

vfprintf is entangled with vfwprintf (of course), __printf_fp,
__printf_fphex, __vstrfmon_l_internal, and the strfrom family of
functions.  The latter use the internal snprintf functionality,
so vsnprintf is converted as well.

The simples conversion is __printf_fphex, followed by
__vstrfmon_l_internal and __printf_fp, and finally
__vfprintf_internal and __vfwprintf_internal.  __vsnprintf_internal
and strfrom* are mostly consuming the new interfaces, so they
are comparatively simple.

__printf_fp is a public symbol, so the FILE *-based interface
had to preserved.

The __printf_fp rewrite does not change the actual binary-to-decimal
conversion algorithm, and digits are still not emitted directly to
the target buffer.  However, the staging buffer now uses bytes
instead of wide characters, and one buffer copy is eliminated.

The changes are at least performance-neutral in my testing.
Floating point printing and snprintf improved measurably, so that
this Lua script

  for i=1,5000000 do
      print(i, i * math.pi)
  end

runs about 5% faster for me.  To preserve fprintf performance for
a simple "%d" format, this commit has some logic changes under
LABEL (unsigned_number) to avoid additional function calls.  There
are certainly some very easy performance improvements here: binary,
octal and hexadecimal formatting can easily avoid the temporary work
buffer (the number of digits can be computed ahead-of-time using one
of the __builtin_clz* built-ins). Decimal formatting can use a
specialized version of _itoa_word for base 10.

The existing (inconsistent) width handling between strfmon and printf
is preserved here.  __print_fp_buffer_1 would have to use
__translated_number_width to achieve ISO conformance for printf.

Test expectations in libio/tst-vtables-common.c are adjusted because
the internal staging buffer merges all virtual function calls into
one.

In general, stack buffer usage is greatly reduced, particularly for
unbuffered input streams.  __printf_fp can still use a large buffer
in binary128 mode for %g, though.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

stdio-common: Add __translated_number_width

This function will be used to compute the width of a number
after i18n digit translation.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

stdio-common: Add __printf_function_invoke

And __wprintf_function_invoke.  These functions will be used to
to call registered printf specifier callbacks on printf buffers
after vfprintf and vfwprintf have been converted to buffers.  The new
implementation avoids alloca/variable length arrays.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

stdio-common: Introduce buffers for implementing printf

These buffers will eventually be used instead of FILE * objects
to implement printf functions.  The multibyte buffer is struct
__printf_buffer, the wide buffer is struct __wprintf_buffer.

To enable writing type-generic code, the header files
printf_buffer-char.h and printf_buffer-wchar_t.h define the
Xprintf macro differently, enabling Xprintf (buffer) to stand
for __printf_buffer and __wprintf_buffer as appropriate.  For
common cases, macros like Xprintf_buffer are provided as a more
syntactically convenient shortcut.

Buffer-specific flush callbacks are implemented with a switch
statement instead of a function pointer, to avoid hardening issues
similar to those of libio vtables.  struct __printf_buffer_as_file
is needed to support custom printf specifiers because the public
interface for that requires passing a FILE *, which is why there
is a trapdoor back from these buffers to FILE * streams.

Since the immediate user of these interfaces knows when processing
has finished, there is no flush callback for the end of processing,
only a flush callback for the intermediate buffer flush.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

locale: Implement struct grouping_iterator

The iterator allows grouping while scanning forward through
the digits.  This enables emitting digits as they are processed.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Use Linux 6.1 in build-many-glibcs.py

This patch makes build-many-glibcs.py use Linux 6.1.

Tested with build-many-glibcs.py (host-libraries, compilers and glibcs
builds).

Avoid use of atoi in some places in libc

This patch is split out of
<https://sourceware.org/pipermail/libc-alpha/2022-December/144122.html>.

atoi has undefined behavior on out-of-range input, which makes it
problematic to use anywhere in glibc that might be processing input
out-of-range for atoi but not specified to produce undefined behavior
for the function calling atoi.  Change some uses of atoi to call
strtol instead; this avoids the undefined behavior, though there is no
guarantee that the overflow handling of strtol is really right in
those places either.  This also serves to avoid localplt test failures
given an installed header redirection for strtol (which means that the
call from the inline atoi implementation doesn't end up at a hidden
alias from libc_hidden_proto).

Certainly, the use of atoi is questionable in argp-help.c (shared with
gnulib, so shouldn't depend on glibc implementation details, and
processing user-provided input), and maybe also in argp-parse.c (I'm
not sure what that code in argp-parse.c is meant to be used for).  I
also changed inet/rexec.c and resolv/res_init.c similarly to use
strtol to avoid such localplt failures, although given those files (in
those versions) are only used in glibc it's not problematic for them
to rely on the specific behavior of glibc's atoi on out-of-range input
(in the absence of compiler optimizations based on the undefined
behavior) in the same way it's problematic for gnulib code to do so.

There may be other uses of atoi (or atol or atoll), in any of glibc's
installed code, for which it would also be appropriate to avoid the
undefined behavior on out-of-range input; this patch only fixes the
specific cases needed to avoid localplt failures.

Tested for x86_64.

Linux: Remove epoll_create, inotify_init from syscalls.list

Their presence causes stub warnings to be created on architectures
which do not implement them.

Fixes commit d1d23b134244d59c4d6ef2295 ("Lninux: consolidate
epoll_create implementation") and commit 842128f160a48e5545900ea3b
("Linux: consolidate inotify_init implementation").

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Linux: Reflow and sort some Makefile variables

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

mach: Drop remnants of old_CFLAGS

mach: Fix passing -ffreestanding when checking for gnumach headers

8b8c768e3c70 ("Force use of -ffreestanding when checking for gnumach
headers") was passing -ffreestanding to CFLAGS only, but headers checks are
performed with the preprocessor, so we rather need to pass it to CPPFLAGS.

Force use of -ffreestanding when checking for gnumach headers

Without this ./configure assumes that we are in a fully hosted
environment, which might not be the case. After this patch, we can rely on
the freestanding header files provided by GCC such as stdint.h.
Message-Id: <Y5+0V9osFc/zXMq0@mars>

elf: Fix tst-relro-symbols.py argument passing

Current scheme only consideres the first argument for both --required
and --optional, where the idea is to append a new item.

Checked on x86_64-linux-gnu.

Reviewed-by: Florian Weimer <fweimer@redhat.com>

x86: Prevent SIGSEGV in memcmp-sse2 when data is concurrently modified [BZ #29863]

In the case of INCORRECT usage of `memcmp(a, b, N)` where `a` and `b`
are concurrently modified as `memcmp` runs, there can be a SIGSEGV
in `L(ret_nonzero_vec_end_0)` because the sequential logic
assumes that `(rdx - 32 + rax)` is a positive 32-bit integer.

To be clear, this change does not mean the usage of `memcmp` is
supported.  The program behaviour is undefined (UB) in the
presence of data races, and `memcmp` is incorrect when the values
of `a` and/or `b` are modified concurrently (data race). This UB
may manifest itself as a SIGSEGV. That being said, if we can
allow the idiomatic use cases, like those in yottadb with
opportunistic concurrency control (OCC), to execute without a
SIGSEGV, at no cost to regular use cases, then we can aim to
minimize harm to those existing users.

The fix replaces a 32-bit `addl %edx, %eax` with the 64-bit variant
`addq %rdx, %rax`. The 1-extra byte of code size from using the
64-bit instruction doesn't contribute to overall code size as the
next target is aligned and has multiple bytes of `nop` padding
before it. As well all the logic between the add and `ret` still
fits in the same fetch block, so the cost of this change is
basically zero.

The relevant sequential logic can be seen in the following
pseudo-code:
```
    /*
     * rsi = a
     * rdi = b
     * rdx = len - 32
     */
    /* cmp a[0:15] and b[0:15]. Since length is known to be [17, 32]
    in this case, this check is also assumed to cover a[0:(31 - len)]
    and b[0:(31 - len)].  */
    movups  (%rsi), %xmm0
    movups  (%rdi), %xmm1
    PCMPEQ  %xmm0, %xmm1
    pmovmskb %xmm1, %eax
    subl    %ecx, %eax
    jnz L(END_NEQ)

    /* cmp a[len-16:len-1] and b[len-16:len-1].  */
    movups  16(%rsi, %rdx), %xmm0
    movups  16(%rdi, %rdx), %xmm1
    PCMPEQ  %xmm0, %xmm1
    pmovmskb %xmm1, %eax
    subl    %ecx, %eax
    jnz L(END_NEQ2)
    ret

L(END2):
    /* Position first mismatch.  */
    bsfl    %eax, %eax

    /* The sequential version is able to assume this value is a
    positive 32-bit value because the first check included bytes in
    range a[0:(31 - len)] and b[0:(31 - len)] so `eax` must be
    greater than `31 - len` so the minimum value of `edx` + `eax` is
    `(len - 32) + (32 - len) >= 0`. In the concurrent case, however,
    `a` or `b` could have been changed so a mismatch in `eax` less or
    equal than `(31 - len)` is possible (the new low bound is `(16 -
    len)`. This can result in a negative 32-bit signed integer, which
    when zero extended to 64-bits is a random large value this out
    out of bounds. */
    addl %edx, %eax

    /* Crash here because 32-bit negative number in `eax` zero
    extends to out of bounds 64-bit offset.  */
    movzbl  16(%rdi, %rax), %ecx
    movzbl  16(%rsi, %rax), %eax
```

This fix is quite simple, just make the `addl %edx, %eax` 64 bit (i.e
`addq %rdx, %rax`). This prevents the 32-bit zero extension
and since `eax` is still a low bound of `16 - len` the `rdx + rax`
is bound by `(len - 32) - (16 - len) >= -16`. Since we have a
fixed offset of `16` in the memory access this must be in bounds.

Allow _Qp_fgt in sparc64 localplt.data

A recent GCC change resulted in localplt test failures on sparc64
because of references to _Qp_fgt.  This is analogous to all the other
floating-point symbols allowed in localplt.data, so it seems
appropriate to allow this one as well.

Tested with build-many-glibcs.py for sparc64-linux-gnu (GCC mainline),
where it fixes the test failure.