Tarantool development patches archive
 help / color / mirror / Atom feed
From: "Timur Safin" <tsafin@tarantool.org>
To: 'Vladislav Shpilevoy' <v.shpilevoy@tarantool.org>,
	tarantool-patches@dev.tarantool.org, avtikhon@tarantool.org
Subject: Re: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c
Date: Wed, 20 May 2020 10:26:48 +0300	[thread overview]
Message-ID: <384c01d62e78$066824d0$13386e70$@tarantool.org> (raw)
In-Reply-To: <a7442474017849f773fc0470c14df3845b9c84ab.1589931033.git.v.shpilevoy@tarantool.org>

Yup, let's hack a problem with using hack! 
(Though using entirely hacking approaches in this particular case
is most consistent)

LGTM

Timur

: -----Original Message-----
: From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
: Sent: Wednesday, May 20, 2020 2:31 AM
: To: tarantool-patches@dev.tarantool.org; tsafin@tarantool.org;
: avtikhon@tarantool.org
: Subject: [PATCH 1/1] build: turn off LTO for exports.c
: 
: 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 <symbol>(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)

  reply	other threads:[~2020-05-20  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 23:31 Vladislav Shpilevoy
2020-05-20  7:26 ` Timur Safin [this message]
2020-05-25 17:13 ` Alexander V. Tikhonov
2020-05-25 19:02 ` Vladislav Shpilevoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='384c01d62e78$066824d0$13386e70$@tarantool.org' \
    --to=tsafin@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox