| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There is no need to use TESTL when checking the least-significant bit
with a TEST instruction. Use TESTB, which is three bytes shorter:
f6 44 24 04 01 testb $0x1,0x4(%esp)
vs:
f7 44 24 04 01 00 00 testl $0x1,0x4(%esp)
00
for the same effect.
No functional changes intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Cc: H.J.Lu <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
|
|
There is no need to use TESTL when checking the least-significant bit
with a TEST instruction. Use TESTB, which is three bytes shorter:
f6 44 24 f0 01 testb $0x1,-0x10(%rsp)
vs:
f7 44 24 f0 01 00 00 testl $0x1,-0x10(%rsp)
00
for the same effect.
No functional changes intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Cc: H.J.Lu <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix a bug in predicate logic introduced in last change.
A slight performance improvement from relying on all true
predicates during conversion from single to double.
This fixes BZ #33299.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
|
|
When testing with some kernel versions, support FUSE infrastructure
encounters a FUSE_GETXATTR request, leading to FUSE tests hanging until
timed out. Therefore, pass FUSE_GETXATTR requests from
support_fuse_handle_mountpoint to support_fuse_handle_directory, and
adjust support_fuse_handle_directory to return ENOSYS so that tests can
proceed.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
When transparent hugepages (THP) are configured to 32MB on x86/loongarch
systems, the current big_size value may not be sufficiently large to
guarantee that free(ptr) [1] will call munmap(ptr_aligned, big_size).
Tested on x86_64 and loongarch64.
PS: Without this patch and using 32M THP, there is a about 50% chance
that malloc/tst-free-errno-malloc-hugetlb1 will fail on both x86_64 and
loongarch64.
[1] malloc/tst-free-errno.c:
...
errno = 1789;
/* This call to free() is supposed to call
munmap (ptr_aligned, big_size);
which increases the number of VMAs by 1, which is supposed
to fail. */
-> free (ptr);
TEST_VERIFY (get_errno () == 1789);
}
...
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
|
|
Since the GNU2 TLS run-time bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31372
affects both i386 and x86-64, also add GLIBC_ABI_GNU2_TLS version to i386
to indicate the working GNU2 TLS run-time. For x86-64, the additional
GNU2 TLS run-time bug fix is needed for
https://sourceware.org/bugzilla/show_bug.cgi?id=31501
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Message-ID: <20250817104023.91919-8-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-7-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-6-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-5-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-4-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-3-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-2-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-20-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-19-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-18-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-17-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-16-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-15-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-14-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-13-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-12-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-11-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-10-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-9-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-8-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-7-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-6-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-5-gfleury@disroot.org>
|
|
into libc.
Message-ID: <20250815181500.107433-4-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-3-gfleury@disroot.org>
|
|
Message-ID: <20250815181500.107433-2-gfleury@disroot.org>
|
|
When the linker -z mark-plt option is used to add DT_X86_64_PLT,
DT_X86_64_PLTSZ and DT_X86_64_PLTENT, the r_addend field of the
R_X86_64_JUMP_SLOT relocation stores the offset of the indirect
branch instruction. However, glibc versions without the commit:
commit f8587a61892cbafd98ce599131bf4f103466f084
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri May 20 19:21:48 2022 -0700
x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT
According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT
and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we
can ignore their r_addends.
Reviewed-by: Fangrui Song <maskray@google.com>
won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation.
Such programs and shared libraries will fail at run-time randomly.
Add GLIBC_ABI_DT_X86_64_PLT version to indicate that glibc is compatible
with DT_X86_64_PLT.
The linker can add the glibc GLIBC_ABI_DT_X86_64_PLT version dependency
whenever -z mark-plt is passed to the linker. The resulting programs and
shared libraries will fail to load at run-time against libc.so without the
GLIBC_ABI_DT_X86_64_PLT version, instead of fail randomly.
This fixes BZ #33212.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
On i386, programs and shared libraries with __thread usage may fail
silently at run-time against glibc without the TLS run-time fix for:
https://sourceware.org/bugzilla/show_bug.cgi?id=32996
Add GLIBC_ABI_GNU_TLS version to indicate that glibc has the working
GNU TLS run-time. Linker can add the GLIBC_ABI_GNU_TLS version to
binaries which depend on the working TLS run-time so that such programs
and shared libraries will fail to load and run at run-time against
libc.so without the GLIBC_ABI_GNU_TLS version, instead of fail silently
at random.
This fixes BZ #33221.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Programs and shared libraries compiled with -mtls-dialect=gnu2 may fail
silently at run-time against glibc without the GNU2 TLS run-time fix
for:
https://sourceware.org/bugzilla/show_bug.cgi?id=31372
Add GLIBC_ABI_GNU2_TLS version to indicate that glibc has the working
GNU2 TLS run-time. Linker can add the GLIBC_ABI_GNU2_TLS version to
binaries which depend on the working GNU2 TLS run-time:
https://sourceware.org/bugzilla/show_bug.cgi?id=33130
so that such programs and shared libraries will fail to load and run at
run-time against libc.so without the GLIBC_ABI_GNU2_TLS version, instead
of fail silently at random.
This fixes BZ #33129.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
GCC parts:
A GCC bug caused the loss of the search path: /usr/lib64/sf, and this
bug has now been fixed in GCC.
See:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9467435253948b83fcb5f7430f6cd571236960d8
|
|
Use uint16_t rather than uint8_t for the size arrays.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
|
The use of the same name for a local variable combined with passing a
pointer to it to a nested macro call causes the wrong 'err' variable to
be updated in 'read_real', because '&err' is only expanded at '*errp'
evaluation. Consequently the variable defined in 'read_real' is set
rather than one in its 'verify_input' caller as it would be the case
should 'read_real' be a function, leading to invalid input such as:
%a:nan:1:3:nan(:
to be accepted.
Address the issue by renaming the 'err' variable in 'verify_input' to
'errx', causing such input to be correctly rejected:
error: ./tst-scanf-format-skeleton.c:242: input line 1: input data format error
No test case added as it's a test case issue in the first place.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Verify that . input is rejected by 'f' conversion (and its uppercase
counterpart). Replace 0 input with .0 rather than adding new one,
because the integral part of 0 is already covered by 0.0 data, so
there's no need to keep this duplication.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Verify that . input is rejected by 'e' conversion (and its uppercase
counterpart). Replace 0e0 input with .0e0 rather than adding new one,
because 0 significand is already covered by 0e+0 data, so there's no
need to keep this duplication.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Verify that 0x. input is rejected by 'a' and 'g' conversions (and their
uppercase counterparts). Replace 0x0p0 input with 0x.0p0 rather than
adding new one, because 0x0 significand is already covered by 0x0p+0
data, so there's no need to keep this duplication.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Reject invalid formatted scanf real input data the significand part of
which is comprised of a hexadecimal prefix followed by a decimal point
only, optionally preceded by a sign. Such data is a prefix of, but not
a matching input sequence and it is required by ISO C to cause a
matching failure.
Currently a matching success is instead incorrectly produced along with
the conversion result of zero, with data up to and including the decimal
point consumed from input.
Technically this change also causes lone . to be rejected early, though
it doesn't change semantics, because unlike 0x. it's not valid input to
'strtod', etc. so it gets rejected at actual conversion time later on
anyway.
Test cases follow as separate changes.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Fix a code pattern that repeats across '__vfscanf_internal' where the
remaining field width of 0 is incorrectly interpreted as no width limit,
which in turn results in reading input beyond the limit requested. The
lack of width limit is indicated by the field width of -1 rather than 0,
set earlier on in the function.
The problematic code pattern is used for both integer and floating-point
conversions, but in the former case a corresponding conditional earlier
on prevents the field width from being 0 when executing the pattern. It
does trigger in the latter case, where the decimal point is a multibyte
character or for multibyte digit characters.
Fix the code pattern by using 'width > 0' comparison, and apply the fix
throughout even to code handling integer conversions so as to interpret
the field width consistently and avoid people's confusion even if width
cannot be 0 at those places.
For multibyte digit characters there is an additional issue that causes
code to push back a partially fetched multibyte character multiple times
as execution proceeds through matching data retrieved against individual
digits that have to be rejected due to the field width limit preventing
the rest of the multibyte character from being retrieved. It is because
code relies on 'ungetc' ignoring a request to push back EOF, however in
the out-of-limit field width condition the data held is not EOF but the
previously retrieved character byte instead.
Fix this issue by artificially assigning EOF to the character byte
storage variable where the out-of-limit field width condition prevents
further processing, and also apply the fix throughout except for the
decimal point/thousands separator case, which uses different code.
Add test cases accordingly.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
tcache_key is unsigned so we should turn it explicitly to signed before
taking its absolute value.
|
|
We want tcache_key not to be a commonly-occurring value in memory, so ensure
a minimum amount of one and zero bits.
And we need it non-zero, otherwise even if tcache_double_free_verify sets
e->key to 0 before calling __libc_free, it gets called again by __libc_free,
thus looping indefinitely.
Fixes: c968fe50628db74b52124d863cd828225a1d305c ("malloc: Use tailcalls in __libc_free")
|
|
On a Linux system you have two sources for locales: glibc and ICU.
ICU offeres a lot more languages than glibc. Especially when it comes to
en_*.
If you have an English system and want to use ISO8601 for date and time
format there is only one locale which can be used for that: en_SE
However ICU offers en_SE and glibc doesn't. If you set LC_TIME=en_SE a
lot of application wont start, because the locale is not known to glibc.
https://sourceware.org/bugzilla/show_bug.cgi?id=33190
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Mike FABIAN <mfabian@redhat.com>
|
|
MALLOC_DEBUG only works on locked arenas, so move the call to
check_inuse_chunk from __libc_free() to _int_free_chunk().
Regress now passes if MALLOC_DEBUG is enabled.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Arenas support huge pages but not transparent huge pages. Add this by
also checking mp_.thp_pagesize when creating a new arena, and use madvise.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Remove an odd use of __curbrk and use MORECORE (0) instead.
This fixes Hurd build since it doesn't define this symbol.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Assembler files may want or need to test for predefined macros which are
set via -m* compiler options, so ensure all -m* options in CFLAGS are passed
to ASFLAGS.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
