Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: tarantool-patches@dev.tarantool.org, tsafin@tarantool.org,
	avtikhon@tarantool.org
Subject: [Tarantool-patches] [PATCH 1/1] build: turn off LTO for exports.c
Date: Wed, 20 May 2020 01:31:27 +0200	[thread overview]
Message-ID: <a7442474017849f773fc0470c14df3845b9c84ab.1589931033.git.v.shpilevoy@tarantool.org> (raw)

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-19 23:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 23:31 Vladislav Shpilevoy [this message]
2020-05-20  7:26 ` Timur Safin
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=a7442474017849f773fc0470c14df3845b9c84ab.1589931033.git.v.shpilevoy@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=avtikhon@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=tsafin@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