[Bug general/29141] New: _FORTIFY_SOURCE=3 fail for gcc 12/glibc 2.35
https://sourceware.org/bugzilla/show_bug.cgi?id=29141 Bug ID: 29141 Summary: _FORTIFY_SOURCE=3 fail for gcc 12/glibc 2.35 Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: p...@void-ptr.info CC: elfutils-devel at sourceware dot org Target Milestone: --- Hi, _FORTIFY_SOURCE=3 fail to compile with gcc 12/glibc 2.35. Used: (GCC) 12.0.1 20220504 (prerelease) glibc ec5b79aac768 (release/2.35/master) In file included from /x86_64-unknown-linux-gnu/usr/include/features.h:490, from .../x86_64-unknown-linux-gnu/usr/include/assert.h:35, from elf_getarsym.c:34: In function ‘pread’, inlined from ‘pread_retry’ at ../lib/system.h:188:21, inlined from ‘read_number_entries’ at elf_getarsym.c:63:21, inlined from ‘elf_getarsym’ at elf_getarsym.c:172:11: /x86_64-unknown-linux-gnu/usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ specified size between 9223372036854775813 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 74 | return __glibc_fortify (pread, __nbytes, sizeof (char), | ^~~ elf_getarsym.c: In function ‘elf_getarsym’: elf_getarsym.c:56:5: note: destination object allocated here 56 | } u; | ^ /x86_64-unknown-linux-gnu/usr/include/bits/unistd.h:50:16: note: in a call to function ‘__pread_alias’ declared with attribute ‘access (write_only, 2, 3)’ 50 | extern ssize_t __REDIRECT (__pread_alias, |^~ In file included from /x86_64-unknown-linux-gnu/usr/include/features.h:490, from /x86_64-unknown-linux-gnu/usr/include/assert.h:35, from elf_getarsym.c:34: In function ‘pread’, inlined from ‘pread_retry’ at ../lib/system.h:188:21, inlined from ‘read_number_entries’ at elf_getarsym.c:63:21, inlined from ‘elf_getarsym’ at elf_getarsym.c:172:11: .../x86_64-unknown-linux-gnu/usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ specified size between 9223372036854775813 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 74 | return __glibc_fortify (pread, __nbytes, sizeof (char), | ^~~ elf_getarsym.c: In function ‘elf_getarsym’: elf_getarsym.c:56:5: note: destination object allocated here 56 | } u; | ^ .../x86_64-unknown-linux-gnu/usr/include/bits/unistd.h:50:16: note: in a call to function ‘__pread_alias’ declared with attribute ‘access (write_only, 2, 3)’ 50 | extern ssize_t __REDIRECT (__pread_alias, Lower level (_FORTIFY_SOURCE=2) compiled fine. Tricks similar to suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397 not help: warning disappear only when I set wrong condition if (w >= sizeof(u)) __builtin_unreachable(); (should be w > sizeof(u)). -- - ptr -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/29141] _FORTIFY_SOURCE=3 fail for gcc 12/glibc 2.35
https://sourceware.org/bugzilla/show_bug.cgi?id=29141
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org,
||siddhesh at sourceware dot org
--- Comment #1 from Mark Wielaard ---
This is interesting. I recently fixed a similar warning in gdb (also for
-Werror=stringop-overflow, but not _FORTIFY_SOURCE related):
https://sourceware.org/pipermail/gdb-patches/2022-May/188694.html
I have added Siddhesh to the CC who might have seen this earlier.
Background is that in elfutils we are trying to use _FORTIFY_SOURCE=3 when it
is available using this configure snippet:
# See if we can add -D_FORTIFY_SOURCE=2 or =3. Don't do it if it is already
# (differently) defined or if it generates warnings/errors because we
# don't use the right optimisation level (string.h will warn about that).
AC_MSG_CHECKING([whether to add -D_FORTIFY_SOURCE=2 or =3 to CFLAGS])
case "$CFLAGS" in
*-D_FORTIFY_SOURCE=*)
AC_MSG_RESULT([no, already there])
;;
*)
save_CFLAGS="$CFLAGS"
# Try 3 first.
CFLAGS="-D_FORTIFY_SOURCE=3 $save_CFLAGS -Werror"
fortified_cflags=""
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
#include
int main() { return 0; }
]])], [ AC_MSG_RESULT([yes -D_FORTIFY_SOURCE=3])
fortified_cflags="-D_FORTIFY_SOURCE=3" ], [])
# If that didn't work, try 2.
if test -z "$fortified_cflags"; then
CFLAGS="-D_FORTIFY_SOURCE=2 $save_CFLAGS -Werror"
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
#include
int main() { return 0; }
]])], [ AC_MSG_RESULT([yes -D_FORTIFY_SOURCE=2])
fortified_cflags="-D_FORTIFY_SOURCE=2" ],
[ AC_MSG_RESULT([no, cannot be used])])
fi
CFLAGS="$fortified_cflags $save_CFLAGS"
CXXFLAGS="$fortified_cflags $CXXFLAGS"
;;
esac
But it seems to produce gcc warnings like the above, so either our configure
foo is bad or we simply have to always use _FORTIFY_SOURCE=2.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/29141] _FORTIFY_SOURCE=3 fail for gcc 12/glibc 2.35
https://sourceware.org/bugzilla/show_bug.cgi?id=29141 --- Comment #2 from Siddhesh Poyarekar --- I can see that it happens with the latest glibc snapshot in rawhide too. For some reason the fortified function doesn't get simplified (i.e. choose between __pread_alias and __pread_chk at compile time, not just emit both) with _FORTIFY_SOURCE=3 and I need to figure out why. I'll dig into this. Please keep it with elfutils for now. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] debuginfod: Try without MHD_USE_DUAL_STACK if MHD_start_daemon fails
Hi, On Fri, May 06, 2022 at 12:37:35AM +0200, Mark Wielaard wrote: > On a systems that have ipv6 disabled debuginfod doesn't start up > anymore because libhttpd MHD_USE_DUAL_STACK only works if it can > open an ipv6 socket. If MHD_start_daemon with MHD_USE_DUAL_STACK > fails try again without that flag set. > > https://sourceware.org/bugzilla/show_bug.cgi?id=29122 Pushed after OK on irc from Frank and some testing in Fedora. Cheers, Mark
[Bug debuginfod/29122] MHD_USE_DUAL_STACK doesn't work when ipv6 is disabled
https://sourceware.org/bugzilla/show_bug.cgi?id=29122 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit 51571ca7685fad821eb98eaa481f64de7f44bb07 Author: Mark Wielaard Date: Thu May 5 23:59:57 2022 +0200 debuginfod: Try without MHD_USE_DUAL_STACK if MHD_start_daemon fails On a systems that have ipv6 disabled debuginfod doesn't start up anymore because libhttpd MHD_USE_DUAL_STACK only works if it can open an ipv6 socket. If MHD_start_daemon with MHD_USE_DUAL_STACK fails try again without that flag set. https://sourceware.org/bugzilla/show_bug.cgi?id=29122 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] debuginfod: Use MHD_USE_EPOLL for libmicrohttpd version 0.9.51 or higher
On Fri, May 06, 2022 at 12:38:40AM +0200, Mark Wielaard wrote: > Also disable MHD_USE_THREAD_PER_CONNECTION when using MHD_USE_EPOLL. Pushed after OK from Frank on irc and some testing in Fedora. Cheers, Mark
[Bug debuginfod/29123] MHD_USE_EPOLL doesn't work
https://sourceware.org/bugzilla/show_bug.cgi?id=29123 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Mark Wielaard --- commit 4b42d9ad28dc0820dc537b442e9dd88138a4b980 Author: Mark Wielaard Date: Fri May 6 00:29:28 2022 +0200 debuginfod: Use MHD_USE_EPOLL for libmicrohttpd version 0.9.51 or higher Also disable MHD_USE_THREAD_PER_CONNECTION when using MHD_USE_EPOLL. https://sourceware.org/bugzilla/show_bug.cgi?id=29123 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
