From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp16.mail.ru (smtp16.mail.ru [94.100.176.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id B628A469710 for ; Mon, 25 May 2020 20:13:53 +0300 (MSK) Date: Mon, 25 May 2020 20:13:51 +0300 From: "Alexander V. Tikhonov" Message-ID: <20200525171351.GA27041@hpalx> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Hi Vlad, thanks a lot for the patch. I've checked it on all test jobs at avtikhon/gh-5001-lto-exports-fnolto-full-ci branch. Results became better: https://gitlab.com/tarantool/tarantool/pipelines/149423666 LTO build passed: https://gitlab.com/tarantool/tarantool/-/jobs/566687392 Test box/push.test.lua failed as expected: https://gitlab.com/tarantool/tarantool/-/jobs/566687395 The new issue will be created on it as we discussed it verbally. Patch LGTM. On Wed, May 20, 2020 at 01:31:27AM +0200, Vladislav Shpilevoy wrote: > There were lots of errors of kind: > > /builds/M4RrgQZ3/0/tarantool/tarantool/src/exports.h:395:1: error: variable ‘uuid_nil’ redeclared as function > EXPORT(uuid_nil) > ^ > /builds/M4RrgQZ3/0/tarantool/tarantool/src/lib/uuid/tt_uuid.c:39:22: note: previously declared here > const struct tt_uuid uuid_nil; > > when LTO was enabled. That happened because exports.c file, to > take symbol addresses, declared lots of functions and variables > from all the code base as > > extern void (void); > > This is crazy, but it worked for normal builds. Because symbol is > symbol. The compilers couldn't find conflicting declarations, > because they never met in one compilation unit. > > However the lie was revealed by linker with LTO enabled. It could > see, that actual symbol definitions didn't match their exports in > exports.c. It could live with mismatching function-function or > variable-variable cases, but couldn't withstand function-variable > mismatches. When a symbol was declared as a variable in one place > and as a function in another. > > This was the case for variables: > - uuid_nil > - tarantool_lua_ibuf > - log_pid > - log_format > - crc32_calc > - _say > - log_level > > The errors were false positive, because the symbols were never > used for anything except taking their addresses. To calm the > linker down exports.c now does not participate in LTO. > > Closes #5001 > --- > Branch: http://github.com/tarantool/tarantool/tree/gerold103/gh-5001-lto-exports-fnolto > Issue: https://github.com/tarantool/tarantool/issues/5001 > > src/CMakeLists.txt | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt > index 7a718fde9..c2fb7841c 100644 > --- a/src/CMakeLists.txt > +++ b/src/CMakeLists.txt > @@ -246,6 +246,19 @@ if(BUILD_STATIC) > endif() > endif() > > +if (ENABLE_LTO) > + # Exports compilation unit is entirely a hack. It references > + # symbols among static libraries and object files declaring > + # them all as functions. To avoid header dependencies. This is > + # not detected by the compilers, since they never see > + # conflicting definitions in one compilation unit. But this > + # makes LTO mad, because the linker sees all the definitions, > + # and is especially angry when a variable is declared as a > + # function. To get rid of these false positive errors the > + # exports file is not link-time optimized. > + set_source_files_properties(exports.c PROPERTIES COMPILE_FLAGS -fno-lto) > +endif() > + > add_executable( > tarantool main.cc exports.c > ${LIBUTIL_FREEBSD_SRC}/flopen.c > -- > 2.21.1 (Apple Git-122.3) >