[Bug lto/66305] -ffat-lto-objects create unreproducible objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305 Peter Wu changed: What|Removed |Added CC||peter at lekensteyn dot nl --- Comment #6 from Peter Wu --- -frandom-seed=0 did not work for me. It appears that since GCC 8 introduced a bug where zero values resulted in a new random value anyway: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=edabe3d8b479e47a1bb3ed495f2a1d94b0ecbb2d Any of these would trigger that problematic case in get_random_seed: -frandom-seed=0 -frandom-seed=0x0 -frandom-seed=jNCWWJ (non-hexadecimal strings are hashed, see set_random_seed) -frandom-seed=1 does seem to result in a reproducible build with GCC 9.2.0, but only as long as the main source file passed to the compiler is a relative path. The main source path is hashed, so if it was absolute, then the source directory would still become part of the build environment: https://github.com/gcc-mirror/gcc/blob/e98ebda074bf8fc5f630a93085af81f52437d851/gcc/tree.c#L9609-L9626 file = LOCATION_FILE (input_location); len = strlen (file); q = (char *) alloca (9 + 19 + len + 1); memcpy (q, file, len + 1); snprintf (q + len, 9 + 19 + 1, "_%08X_" HOST_WIDE_INT_PRINT_HEX, crc32_string (0, name), get_random_seed (false)); ^^ (LOCATION_FILE is unaffected by -ffile-prefix-map, unlike fold_builtin_FILE in gcc/builtins.c for example.)
[Bug sanitizer/84761] AddressSanitizer is not compatible with glibc 2.27 on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761 Peter Wu changed: What|Removed |Added CC||peter at lekensteyn dot nl --- Comment #12 from Peter Wu --- I was not aware of this report or existing patches. The issue is reported in upstream compiler-rt here: https://github.com/google/sanitizers/issues/954 Jakub, according to upstream LLVM the compiler-rt fixes should first enter LLVM and then be merged downstream in GCC, is there any reason to deviate from this process? Upstream does not seem happy about it. Also please see the LLVM review and linked bugs for comments (I think that using confstr is better than dlvsym, nobody uses pre-release glibc for production right?).
[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65530 Peter Wu changed: What|Removed |Added CC||peter at lekensteyn dot nl --- Comment #1 from Peter Wu --- External binutils bug: Linking a MPX instrumented shared object fails with -pie https://sourceware.org/bugzilla/show_bug.cgi?id=20550
[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267 Peter Wu changed: What|Removed |Added CC||peter at lekensteyn dot nl --- Comment #2 from Peter Wu --- Building Wireshark on Arch Linux with the -Wl,--as-needed linker option also results in issues. Example output during the linker stage (with -mmpx -fcheck-pointer-bounds): /usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/libmpxwrappers.so: undefined reference to `get_bd' collect2: error: ld returned 1 exit status $ readelf -s /usr/lib/libmpxwrappers.so.2.0.0 | grep get_bd 8: 0 NOTYPE GLOBAL DEFAULT UND get_bd 72: 0 NOTYPE GLOBAL DEFAULT UND get_bd $ readelf -s /usr/lib/libmpx.so.2.0.0 | grep get_bd 38: 1720 8 FUNCGLOBAL DEFAULT 13 get_bd@@LIBMPX_2.0 115: 1720 8 FUNCGLOBAL DEFAULT 13 get_bd What helped here was explicitly adding -lmpxwrappers -lmpx to the linker flags.
[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270 Peter Wu changed: What|Removed |Added CC||peter at lekensteyn dot nl --- Comment #2 from Peter Wu --- GCC 6.2.1 is still affected by this. In C99 we can get away with flexible array members, but this feature is unfortunately not defined in the C++ specification. The idiom with an array of length 1 is quite common, is it possible to detect that situation and relax the boundaries?
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #9 from Peter Wu --- Tested with clang version 3.7.0 (http://llvm.org/git/clang.git 6b7e300a9c14a2ff364d8ef8a0f7510378f38dbc) (http://llvm.org/git/llvm 258b7710d59c086656f7b26f02326d7ca69d71fd) (http://llvm.org/git/compiler-rt.git 70b3c4464a4067db2cd9862736611fdf6739f451) The output is still: AddressSanitizer can not describe address in more detail (wild memory access suspected). I can however live with the -fno-common workaround (which sounds like a good idea overall). I'll leave it up to you whether it will be closed as WONTFIX. Thanks for your hints!
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #7 from Peter Wu --- (In reply to Kostya Serebryany from comment #6) > > How does your GCC behave with the test case? The sanitizer code in GCC is > > imported from Clang, I believe, so it probably does not crash either? > > I get this: > ~/gcc-inst/bin/gcc -fsanitize=address -static-libasan d.c && ./a.out > AddressSanitizer can not describe address in more detail (wild memory access > suspected). I guess this is better than crashing. Is it possible to report something better? Can't it at least report the type and address? > Did you check the GCC trunk? It took a while to get the build environment, but now I can confirm that I see the same wild memory access error (tested with r221125).
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #5 from Peter Wu --- (In reply to Kostya Serebryany from comment #4) > I think I know what your problem is. > In C, the globals by default have common linkage and asan does not > instrument them at all and thus can not properly report them. > > Use -fno-common with C. > https://code.google.com/p/address-sanitizer/wiki/Flags That seems to work, but if the flag is not set, can't something smarter be done instead of crashing? How does your GCC behave with the test case? The sanitizer code in GCC is imported from Clang, I believe, so it probably does not crash either?
[Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #3 from Peter Wu --- GCC 4.9.2 cannot include the headers, it blows up on lines such as: In file included from /usr/lib/clang/3.5.1/include/sanitizer/common_interface_defs.h:16:0, from /usr/lib/clang/3.5.1/include/sanitizer/asan_interface.h:17, from :1: /usr/lib/clang/3.5.1/include/stddef.h:42:42: error: missing binary operator before token "(" #if !defined(_PTRDIFF_T) || __has_feature(modules) ... (gcc -I/usr/lib/clang/3.5.1/include ...) With clang 3.5.1, it works, but *only* with "-x c++" and not "-x c".
[Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 Bug ID: 65285 Summary: __asan_describe_address crashes when used with global variable Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: peter at lekensteyn dot nl CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org While trying to use __asan_describe_address() on a global variable, it results in an ASAN check failure. (Originally noticed while using it in gdb.) cat <:3 #7 0x7f00a24f87ff in __libc_start_main (/usr/lib/libc.so.6+0x207ff) #8 0x400608 in _start (/tmp/a.out+0x400608) With Clang 3.5.1 (clang 3.5.1-1 on Arch Linux x86_64) the output is: AddressSanitizer can not describe address in more detail (wild memory access suspected). On gcc 4.8.2-19ubuntu1 (Ubuntu 14.04) there is no output. I have not tested with GCC 5 yet, it takes a while to build. Expected result: a line reporting the location of the global variable. Output of `gcc -v` on Arch Linux x86_64: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.9-20150204/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 20150204 (prerelease) (GCC)
[Bug c/60784] Spurious -Wmissing-field-initializers warning for anonymous structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784 --- Comment #8 from Peter Wu --- GCC 5 is OK, the question is whether 4.9 will or will not receive a fix?
[Bug c/60784] Spurious -Wmissing-field-initializers warning for anonymous structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784 --- Comment #7 from Peter Wu --- This bug is still present in GCC 4.9.2 and 4.9.3 (prerelease 20141210). Now building gcc-5-20141207 to verify. (Not sure whether this gets backported to 4.9.x, just checking.) // gcc -Wextra bug.c -o /dev/null // typedef struct HidppMessage { struct { int feature_index; int func; }; } HidppMessage; int main(void) { HidppMessage req = { .feature_index = 0xFF, .func = 1 }; return req.func; } // Strange enough, replacing 0xFF by 0x00 hides the warning.
[Bug other/64046] Malformed .eh_frame generated with LTO, gold and optimization enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64046 --- Comment #2 from Peter Wu --- Since it is only reproducible with ld.gold, I have duplicated the report at https://sourceware.org/bugzilla/show_bug.cgi?id=17639 What about the application of optimization? Doesn't that have something to do with GCC?
[Bug other/64046] New: Malformed .eh_frame generated with LTO, gold and LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64046 Bug ID: 64046 Summary: Malformed .eh_frame generated with LTO, gold and LTO enabled Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: peter at lekensteyn dot nl While trying to track down a weird crash in libunwind, I found that the library I was debugging (libgudev-1.0.so.0.2.0) has a weird .eh_frame. I could minimize the problem to: echo 'int main(void) { return 0; }' > hello.c gcc -shared -Wl,-fuse-ld=gold -fPIC -flto -ffat-lto-objects -O2 hello.c -Wl,--gc-sections readelf --hex-dump=.eh_frame a.out | head -n5 Omitting any of the gcc options would result in a .eh_frame section that does not look odd. Output of readelf follows (note the leading 8 zeroes, and the warning about the invalid FDE length). Hex dump of section '.eh_frame': 0x06b0 1400 0x06c0 017a5200 01781001 1b0c0708 9001 .zR..x.. 0x06d0 c0fe 1c00 0200 0x06e0 2400 3400 $...4... 0x06f0 70fe 3000 000e1046 0e184a0f p...0..F..J. 0x0700 0b770880 003f1a3b 2a332422 .w...?.;*3$" Contents of the .eh_frame section: ZERO terminator 0004 ZERO terminator 0008 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop readelf: Warning: Invalid length 0xfec0 in FDE at 0x20 0020 fec0 001c FDE cie=0008 pc=06d8..06da DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_??? (User defined call frame op: 0x24) This .eh_frame encoding looks strange to me as it does not conform to LSB 4.1[1] nor the AMD64 ABI document. It also trips up Wireshark's ELF dissector. Linux x86_64 GCC versions 4.8.2-1ubuntu6 (Ubuntu 14.04) and 4.9.2-1 (Arch Linux). binutils 2.24-8 (Arch Linux) [1]: https://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html [2]: http://www.x86-64.org/documentation/abi.pdf
[Bug c/60784] New: Spurious -Wmissing-field-initializers warning for anonymous structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60784 Bug ID: 60784 Summary: Spurious -Wmissing-field-initializers warning for anonymous structure Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: peter at lekensteyn dot nl When an anonymous structure gets initialized, gcc always starts complaining about the last field: // gcc -Wextra warn.c -o /dev/null // struct foo { struct { char a; char b; }; }; int main(void) { struct foo test = { .a = 1, .b = 2, }; return test.a == 1; } /// Output: warn.c: In function ‘main’: warn.c:12:9: warning: missing initializer for field ‘b’ of ‘struct ’ [-Wmissing-field-initializers] .b = 2, ^ warn.c:5:14: note: ‘b’ declared here char b; ^ It gets even worse when adding more fields. For fun, add "char c;" between "char a;" and "char b;". The first warning mentions "c", but the line thereafter points to "b": warn.c: In function ‘main’: warn.c:13:9: warning: missing initializer for field ‘c’ of ‘struct ’ [-Wmissing-field-initializers] .b = 2, ^ warn.c:5:14: note: ‘c’ declared here char c; ^ Expected result: no warnings for the first case. This is gcc-multilib 4.8.2-8 on Arch Linux x86_64. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.8-20140206/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.2 20140206 (prerelease) (GCC)