Hello, I get this error when compiling with -Werror=maybe-uninitialized elf_getarsym.c: In function 'elf_getarsym': elf_getarsym.c:200:14: error: 'n' may be used uninitialized in this function [-Werror=maybe-uninitialized] size_t ar_sym_len = (n + 1) * sizeof (Elf_Arsym); I know that read_number_entries define its values unconditionally but it won't hurt to simply use: uint64_t n = 0; Is it ok?
Another case: i386_disasm.c: In function 'i386_disasm': /home/luizluca/prog-local/lede/trunk/staging_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.15/include/fortify/string.h:47:24: error: 'str' may be used uninitialized in this function [-Werror=maybe-uninitialized] (__s < __d && __s + __n > __d)) i386_disasm.c:709:17: note: 'str' was declared here const char *str; This is because of missing: --- a/libcpu/i386_disasm.c +++ b/libcpu/i386_disasm.c @@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu /* Fallthrough */ default: assert (! "INVALID not handled"); + str = ""; } } else
On Dec 31, 2016 00:14, "luizluca at gmail dot com" < sourceware-bugzilla@sourceware.org> wrote: --- a/libcpu/i386_disasm.c +++ b/libcpu/i386_disasm.c @@ -822,6 +822,7 @@ i386_disasm (Ebl *ebl __attribute__((unu /* Fallthrough */ default: assert (! "INVALID not handled"); + str = ""; Or abort() instead? The point is that the assert always fails. Which it does, unless you compile with -DNDEBUG. So just force it? Thanks, Petr
If you are just compiling with non-standard build flags then just add -Wno-error.
Looks like if you compile with non-standard flags and -Wno-error this is fine. Fell free to reopen if you believe this is not the solution.
Mark, I know that both might be a compiler bug. However, the cost of solving them are very low. Yes, I might be compiling elfutils with non-standard options. However, the non-standard might be the standard for some distribution like LEDE/OpenWRT. The alternative for me is not to use -Wno-error but to patch the code (and maintain the patch) until compiler gets it right. I was just hoping that fixing this upstream will help any other elfutils users that need to compile with those non-standard flags on. I'll reopen only once more this bug. If you think that it should not be "fixed" upstream, mark it again as resolved and I'll let it go.
returning to unconfirmed.
Please post how exactly you are configuring the build, compiler (version) and flags used. It would certainly help to have a concrete patch against current git.
./configure is called as: AR="i486-openwrt-linux-musl-gcc-ar" AS="i486-openwrt-linux-musl-gcc -c -Os -pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include -D_GNU_SOURCE" LD=i486-openwrt-linux-musl-ld NM="i486-openwrt-linux-musl-gcc-nm" CC="i486-openwrt-linux-musl-gcc" GCC="i486-openwrt-linux-musl-gcc" CXX="i486-openwrt-linux-musl-g++" RANLIB="i486-openwrt-linux-musl-gcc-ranlib" STRIP=i486-openwrt-linux-musl-strip OBJCOPY=i486-openwrt-linux-musl-objcopy OBJDUMP=i486-openwrt-linux-musl-objdump SIZE=i486-openwrt-linux-musl-size CFLAGS="-Os -pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include -D_GNU_SOURCE " CXXFLAGS="-Os -pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include -D_GNU_SOURCE " CPPFLAGS="-I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include/fortify -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include " LDFLAGS="-L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib -L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/lib -L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/lib -L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/lib -znow -zrelro -L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/lib -Wl,-rpath-link=/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/lib -L/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/lib -Wl,-rpath-link=/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/lib " LIBS="-largp" ./configure --target=i486-openwrt-linux --host=i486-openwrt-linux --build=x86_64-pc-linux-gnu --program-prefix="" --program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --disable-nls --without-lzma My GCC is: i486-openwrt-linux-musl-gcc --version i486-openwrt-linux-musl-gcc (LEDE GCC 5.4.0 r3621-357efba9bb) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is my gcc call that fails: i486-openwrt-linux-musl-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/share/locale"' -I. -I.. -I. -I. -I../lib -I.. -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/usr/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include/fortify -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/toolchain-i386_pentium4_gcc-5.4.0_musl/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition -Wstrict-prototypes -Wlogical-op -Werror -Wunused -Wextra -Wstack-usage=262144 -Os -pipe -march=pentium4 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/home/REDETRESC/luizluca/prog-local/lede/trunk/build_dir/target-i386_pentium4_musl/elfutils-0.168:elfutils-0.168 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libiconv-stub/include -I/home/REDETRESC/luizluca/prog-local/lede/trunk/staging_dir/target-i386_pentium4_musl/usr/lib/libintl-stub/include -D_GNU_SOURCE -DBAD_FTS=1 -MT elf_getarsym.o -MD -MP -MF .deps/elf_getarsym.Tpo -c -o elf_getarsym.o elf_getarsym.c elf_getarsym.c: In function 'elf_getarsym': elf_getarsym.c:206:11: error: 'n' may be used uninitialized in this function [-Werror=maybe-uninitialized] size_t sz = n * w;
That is a pretty involved way to configure elfutils. You do add various -Wno-error=unused-but-set-variable -Wno-error=unused-result options. Why not just add -Wno-error=maybe-uninitialized in that case?
So the flag that seem to trigger it is -Os (but only on 32bit systems?). Proposed the following: commit 7114c513fbebcca8b76796b7f64b57447ba383e1 Author: Mark Wielaard <mark@klomp.org> Date: Wed Apr 19 17:07:46 2017 +0200 libelf: Initialize n to zero in elf_getarsym. When building with gcc -Os it seems we can inline read_number_entries but if that function fails then n will not be initialized. GCC seems not to realize that in that case n won't be used at all. Explicitly initialize n to zero to prevent a spurious error: 'n' may be used uninitialized in this function [-Werror=maybe-uninitialized] in that case. https://sourceware.org/bugzilla/show_bug.cgi?id=21011 Signed-off-by: Mark Wielaard <mark@klomp.org> https://sourceware.org/ml/elfutils-devel/2017-q2/msg00042.html
Great! Thanks! How about libcpu/i386_disasm.c case?
(In reply to Luiz Angelo Daros de Luca from comment #12) > Great! Thanks! > > How about libcpu/i386_disasm.c case? Don't use -DNDEBUG. assert is a noreturn function. The asserts in the code are deliberately there. If they fail something is seriously wrong.
I do not set -DNDEBUG. All compiler flags are similar in this case. Maybe a gcc bug?
(In reply to Luiz Angelo Daros de Luca from comment #14) > I do not set -DNDEBUG. All compiler flags are similar in this case. Maybe a > gcc bug? Or your alternative glibc headers don't provide enough information about assert to the compiler?
commit 7114c513fbebcca8b76796b7f64b57447ba383e1 Author: Mark Wielaard <mark@klomp.org> Date: Wed Apr 19 17:07:46 2017 +0200 libelf: Initialize n to zero in elf_getarsym. When building with gcc -Os it seems we can inline read_number_entries but if that function fails then n will not be initialized. GCC seems not to realize that in that case n won't be used at all. Explicitly initialize n to zero to prevent a spurious error: 'n' may be used uninitialized in this function [-Werror=maybe-uninitialized] in that case. https://sourceware.org/bugzilla/show_bug.cgi?id=21011 Signed-off-by: Mark Wielaard <mark@klomp.org> Pushed to master.
> Or your alternative glibc headers don't provide enough information about > assert to the compiler? musl dropped the attribute noreturn, which got reverted sometime after. http://www.openwall.com/lists/musl/2016/08/30/1 So, after using a recent musl, libcpu/i386_disasm.c is not an issue anymore. Thanks!