* HAGIO KAZUHITO(萩尾 一仁): >>> I could not find this line in the latest GDB source and the related >>> patches. What is this for? >> >> We need to sync this again with gnulib/GDB. It was added here, in >> glibc, which is the primary source of this file: > > I see, thanks. > >> >> commit 2337e04e21ba6040926ec871e403533f77043c40 >> Author: Siddhesh Poyarekar <siddhesh@xxxxxxxxxxxxxx> >> Date: Thu Feb 2 07:49:02 2023 -0500 >> >> cdefs: Limit definition of fortification macros >> >> Define the __glibc_fortify and other macros only when __FORTIFY_LEVEL > >> 0. This has the effect of not defining these macros on older C90 >> compilers that do not have support for variable length argument lists. >> >> Also trim off the trailing backslashes from the definition of >> __glibc_fortify and __glibc_fortify_n macros. >> >> Signed-off-by: Siddhesh Poyarekar <siddhesh@xxxxxxxxxxxxxx> >> Reviewed-by: Florian Weimer <fweimer@xxxxxxxxxx> >> >> I should have made a note that this is coming from the ultimate upstream >> sources. >> >> I raised the issue of <sys/cdefs.h> syncing here: >> >> Updating <sys/cdefs.h> in glibc and gnulib >> <https://sourceware.org/pipermail/libc-alpha/2023-February/145758.html> Regarding cdefs.h, there's another aspect that I had missed when I wrote the aboce: for future 2.34-based distros (CentOS 9 Stream today, Red Hat Enterprise Linux 9.2 when it comes out), I believe the gnulib/glibc cdefs.h handshake has been fixed with a glibc change: the glibc header now defines the __attribute_nonnull__ macro, which gnulib uses as an indicator that the header is recent enough, so it won't interpose its own version. So hopefully this is going to be more stable in the future, and future such syncs become less necessary. > True, but there is no plan to update the embedded GDB for now and it > would be better to sync with the upstream code just in case, so I've > updated some hunks like so. Does the attached patch work for you? I can confirm this patch passes build testing with an instrumented compiler that logs C99 compatibility issues. Thanks, Florian -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
