[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 peter at lekensteyn dot nl --- 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 peter at lekensteyn dot nl --- (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] 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 SOURCE | ${CC:-cc} -fsanitize=address -g -x c - ./a.out
int foo[10];
int main(void) {
return __asan_describe_address(foo);
}
SOURCE
Output with GCC 4.9.2 (gcc-multilib 4.9.2-3 on Arch Linux x86_64):
==6238==AddressSanitizer CHECK failed:
/build/gcc-multilib/src/gcc-4.9-20150204/libsanitizer/sanitizer_common/sanitizer_linux.cc:558
((MtxUnlocked)) != ((atomic_load(m, memory_order_relaxed))) (0x0, 0x0)
#0 0x7f00a28d8030 in __asan::AsanCheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long) (/usr/lib/libasan.so.1+0x5d030)
#1 0x7f00a28dc293 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long) (/usr/lib/libasan.so.1+0x61293)
#2 0x7f00a28df795 in __sanitizer::BlockingMutex::CheckLocked()
(/usr/lib/libasan.so.1+0x64795)
#3 0x7f00a28da601 in __asan::FindThreadByStackAddress(unsigned long)
(/usr/lib/libasan.so.1+0x5f601)
#4 0x7f00a28d60d0 in __asan::DescribeAddressIfStack(unsigned long, unsigned
long) (/usr/lib/libasan.so.1+0x5b0d0)
#5 0x7f00a28d6552 in __asan::DescribeAddress(unsigned long, unsigned long)
(/usr/lib/libasan.so.1+0x5b552)
#6 0x4006e8 in main /tmp/stdin: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 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 peter at lekensteyn dot nl --- 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 stdin: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] __asan_describe_address crashes when used with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285 --- Comment #5 from Peter Wu peter at lekensteyn dot nl --- (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 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 peter at lekensteyn dot nl ---
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 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 peter at lekensteyn dot nl --- GCC 5 is OK, the question is whether 4.9 will or will not receive a fix?
[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 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 peter at lekensteyn dot nl --- 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 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 anonymous’
[-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 anonymous’
[-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)
