--- Comment #14 from Дилян Палаузов <> ---
Autoconf users willing to compile everything with LTO just by calling
./configure put in /usr/local/etc/

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
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. (-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 -> --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 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
@@ -1,1023 +1,26 @@
        .file   "genoffsets.c"
-       .text
-       .globl  foo
-       .type   foo, @function
-       .file 1 "./auxprogs/genoffsets.c"
-       .loc 1 84 1 view -0
-       .cfi_startproc
-       .loc 1 86 4 view .LVU1
-# 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/ b/
index 4ad5ffa..f36708c 100644
--- a/
+++ b/
@@ -63,9 +63,9 @@ BUILT_SOURCES = pub/libvex_guest_offsets.h
 CLEANFILES    = pub/libvex_guest_offsets.h

-CFLAGS_FOR_GENOFFSETS = $(CFLAGS) -no-integrated-as
+CFLAGS_FOR_GENOFFSETS = -no-integrated-as

 # 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
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

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

You are receiving this mail because:
You are watching all bug changes.

Reply via email to