Compiling the attached readelf.i with -Wall -Werror -O2 using today's gcc mainline on x86_64-linux results in complaints like /home/alan/src/binutils-gdb/binutils/readelf.c: In function ‘find_section’: /home/alan/src/binutils-gdb/binutils/readelf.c:762:42: error: the comparison will always evaluate as ‘true’ for the pointer operand in ‘filedata->section_headers + (sizetype)((long unsigned int)i * 80)’ must not be NULL [-Werror=address] 762 | if (SECTION_NAME_VALID (filedata->section_headers + i) The warning is true, but annoying when coming from a macro expansion #define SECTION_NAME_VALID(X) \ ((X) != NULL \ && filedata->string_table != NULL \ && (X)->sh_name < filedata->string_table_length) In current readelf.c it looks like it may be possible to remove "(X) != NULL" from this macro, but that doesn't seem like a good solution. Another macro with similar complaints #define SECTION_NAME_PRINT(X) \ ((X) == NULL ? _("<none>") \ : filedata->string_table == NULL ? _("<no-strings>") \ : (X)->sh_name >= filedata->string_table_length ? _("<corrupt>") \ : filedata->string_table + (X)->sh_name) can be called with X NULL.
Created attachment 51641 [details] preprocessed source
Confirmed. I wonder if it is possible to omit the warning from chained conditions that are from the same macro expansion. That is, warn when the macro is just #define SECTION_NAME_VALID(X) ((X) != NULL) but not when there's additional conditions on it.
Not that I'm really complaining about this, note also that the error message referencing "filedata->section_headers + (sizetype)((long unsigned int)i * 80)" is a little bit too much of compiler internal representation leaking out. Nowhere in the source is such an expression used. It's simply "filedata->section_headers + i". BTW, the warnings can be avoided by converting the readelf.c macros to inline functions.
The warning for macros was most likely inadvertently enabled in the change for pr102103. In hindsight, I'm guessing it's what triggered the instance in Glibc (since fixed): https://sourceware.org/pipermail/libc-alpha/2021-September/131241.html and I think it might have also been what prompted the change below (I meant to follow up there but got busy with other things): https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580786.html I have a follow-on patch out for review for pr33925. I'll look into the macro suppression at the same time, although I'm not too keen on that idea in general if it can be easily avoided in user code (e.g., inlining). I'd rather get away from it if it's not too painful. The poor format of the expression in the warning is an independent issue worth addressing separately.
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>: https://gcc.gnu.org/g:16137fbb9256ef365dd498d39024eb33de1a4cd8 commit r12-5410-g16137fbb9256ef365dd498d39024eb33de1a4cd8 Author: Martin Sebor <msebor@redhat.com> Date: Fri Nov 19 09:44:31 2021 -0700 Restore ancient -Waddress for weak symbols [PR33925]. Resolves: PR c/33925 - gcc -Waddress lost some useful warnings PR c/102867 - -Waddress from macro expansion in readelf.c gcc/c-family/ChangeLog: PR c++/33925 PR c/102867 * c-common.c (decl_with_nonnull_addr_p): Call maybe_nonzero_address and improve handling tof defined symbols. gcc/c/ChangeLog: PR c++/33925 PR c/102867 * c-typeck.c (maybe_warn_for_null_address): Suppress warnings for code resulting from macro expansion. gcc/cp/ChangeLog: PR c++/33925 PR c/102867 * typeck.c (warn_for_null_address): Suppress warnings for code resulting from macro expansion. gcc/ChangeLog: PR c++/33925 PR c/102867 * doc/invoke.texi (-Waddress): Update. gcc/testsuite/ChangeLog: PR c++/33925 PR c/102867 * g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning. * c-c++-common/Waddress-5.c: New test. * c-c++-common/Waddress-6.c: New test. * g++.dg/warn/Waddress-7.C: New test. * gcc.dg/Walways-true-2.c: Adjust to avoid a valid warning. * gcc.dg/weak/weak-3.c: Expect a warning.
Fixed.