https://bugs.kde.org/show_bug.cgi?id=338252
--- Comment #14 from Дилян Палаузов <dilyan.palau...@aegee.org> --- Autoconf users willing to compile everything with LTO just by calling ./configure put in /usr/local/etc/config.site: CFLAGS="-O3 -fno-fat-lto-objects -flto" CXXFLAGS="-O3 -fno-fat-lto-objects -flto" LDFLAGS="-Wl,-O1,-s -flto=4" And then any ./configure implies LTO. Just as other programs relying on autoconf doing the right thing do not offer --enable-lto option in ./configure --help, can be compiled with LTO, valgrind./configure --help shall not print --enable-lto. Programmer printing on --help "--enable-lto" don't understand autoconf. This applies also for artificially added -g or -O2 from configure.ac or contained in Makefile* ar, nm and ld from binutils can work with LTO, if they are compiled with plugin support binutils-gdb.git/configure --enable-plugins). When gcc calls ld, it passes the plugin path after -plugin, see. https://sourceware.org/binutils/docs/ld/Options.html#Options (-plugin with one dash). Please note, that gcc's "make install" will not install the LTO plugins on the place, where nm will look from it, if it thinks that plugins are needed. See https://sourceware.org/binutils/docs/binutils/nm.html -> --plugins . If `nm --plugin`, `ar --plugin`, `ranlib --plugin` or `ld -plugin` (with one dash) print 'Unknown option', then they are not compiled correctly. The right output of the above commands is "missing argument". The approach for using LTO is to compile ar/ld with plugin support, rather than using gcc-ld/gcc-ar. When CFLAGS from config.site contains -flto, then valgrind can assume that ar/nm/ld are compiled with plugin support. LTO is more than -flto, there is also -fno-fat-lto-objects, and Clang has its own LTO-world. All that said, what is needed for LTO support is stripping the LTO flags when building coregrind/m_libcsetjmp.c, coregrind/m_main.c and VEX/auxprogs/genoffsets.c, assuming that the system is configured correctly with the LTO plugins and ar/ld supporting plugins, or find out why LTO makes problems with those files. Compling everything with LTO produces: In file included from m_syswrap/syswrap-main.c:46: m_syswrap/syswrap-main.c: In function ‘putSyscallStatusIntoGuestState’: m_syswrap/syswrap-main.c:1135:14: error: ‘OFFSET_amd64_RAX’ undeclared (first use in this function) OFFSET_amd64_RAX, sizeof(UWord) ); ^~~~~~~~~~~~~~~~ The diff between VEX/auxprogs/genoffsets.s generated from VEX/auxprogs/genoffsets.c with and without LTO is: --- VEX/auxprogs/genoffsets.s-2 2018-03-12 14:33:05.473476269 +0100 +++ ../valgrind/VEX/auxprogs/genoffsets.s-2 2018-03-12 14:33:14.025483351 +0100 @@ -1,1023 +1,26 @@ .file "genoffsets.c" - .text -.Ltext0: - .globl foo - .type foo, @function -foo: -.LFB17: - .file 1 "./auxprogs/genoffsets.c" - .loc 1 84 1 view -0 - .cfi_startproc - .loc 1 86 4 view .LVU1 -#APP -# 86 "./auxprogs/genoffsets.c" 1 - -#define OFFSET_x86_EAX xyzzy$8 - -# 0 "" 2 - .loc 1 87 4 view .LVU2 -# 87 "./auxprogs/genoffsets.c" 1 - -#define OFFSET_x86_EBX xyzzy$20 - -# 0 "" 2 (- and other OFFSET_ symbols removed) To generate VEX/pub/libvex_guest_offsets.h this "gcc -O -S -o auxprogs/genoffsets.s ./auxprogs/genoffsets.c" is called, and OFFSET_amd64_RAX is in the output if -flto was not passed on this line. This change resolves the mentioned problem with OFFSET_amd64_RAX: diff --git a/Makefile.vex.am b/Makefile.vex.am index 4ad5ffa..f36708c 100644 --- a/Makefile.vex.am +++ b/Makefile.vex.am @@ -63,9 +63,9 @@ BUILT_SOURCES = pub/libvex_guest_offsets.h CLEANFILES = pub/libvex_guest_offsets.h if COMPILER_IS_CLANG -CFLAGS_FOR_GENOFFSETS = $(CFLAGS) -no-integrated-as +CFLAGS_FOR_GENOFFSETS = -no-integrated-as else -CFLAGS_FOR_GENOFFSETS = $(CFLAGS) +CFLAGS_FOR_GENOFFSETS = endif # This is very uggerly. Need to sed out both "xyzzyN" and Now I get: make[3]: Entering directory '/git/valgrind/memcheck' GEN memcheck-amd64-linux m_translate.c: In function ‘vgPlain_translate’: m_translate.c:1527:39: warning: ‘isWrap’ may be used uninitialized in this function [-Wmaybe-uninitialized] m_translate.c:1518:12: note: ‘isWrap’ was declared here m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_gdbserver/server.c:1175: error: undefined reference to 'VG_MINIMAL_SETJMP' m_gdbserver/server.c:1193: error: undefined reference to 'VG_MINIMAL_SETJMP' m_debuginfo/readdwarf3.c:5231: error: undefined reference to 'VG_MINIMAL_SETJMP' m_scheduler/scheduler.c:1005: error: undefined reference to 'VG_MINIMAL_SETJMP' Without -flto: nm coregrind/libcoregrind_amd64_linux_a-m_libcsetjmp.o 0000000000000052 T VG_MINIMAL_LONGJMP 0000000000000000 T VG_MINIMAL_SETJMP with lto: nm coregrind/libcoregrind_amd64_linux_a-m_libcsetjmp.o (nothing) so the asm in coreconf/m_libcsetjmp.c shall be tweeked, in a way that on LTO VG_MINIMAL_LONGJMP and VG_MINIMAL_SETJMP are not optimized out. I don't speak assembler. -- You are receiving this mail because: You are watching all bug changes.
