From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (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 269964696C3 for ; Sun, 19 Apr 2020 01:08:00 +0300 (MSK) From: "Timur Safin" References: <9fc71e590b8d5008dc18fd2314782cdee95cf781.1587167063.git.v.shpilevoy@tarantool.org> <214c01d6157e$7617c460$62474d20$@tarantool.org> In-Reply-To: Date: Sun, 19 Apr 2020 01:07:58 +0300 Message-ID: <001301d615cd$d21c5740$765505c0$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: ru Subject: Re: [Tarantool-patches] [PATCH v2 2/2] cmake: remove dynamic-list linker option List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Vladislav Shpilevoy' , tarantool-patches@dev.tarantool.org : From: Vladislav Shpilevoy : Subject: Re: [PATCH v2 2/2] cmake: remove dynamic-list linker option :=20 : Thanks for the review and the patch! :=20 :=20 ... : The problem here is that the function's result is never used. I am : afraid some smart ass compiler may notice that, since exports.c and : main.cc are built together, and may optimize this call out. Yup, in theory, LTO should be able to proceed cross-function, = intra-module optimizations and figure out that this chains of references = is unnecessary. But I still hope that not all external symbols we = injected would be deleted with LTO. We will need to recheck with LTO = enabled. =20 :=20 : Also return of a value assumes a caller needs to do something with it. : I didn't like that in the Nikolay's solution. I wanted to make a = function, : which does all the work by itself. Returning anything as value was a simple trick to make compiler think = that unused array is used elsewhere. LTO should reveal the truth, = unfortunately.=20 :=20 : However I like that all exports are in a separate file, not surrounded : by hacks of exports.c. So I applied your solution with some code : style problems fixed. Thanks for the help. :=20 : The patch diff is close to 100%, so below is the whole new patch, : without incremental diff. :=20 : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D :=20 : cmake: remove dynamic-list linker option :=20 : dynamic-list (exported_symbols_list on Mac) was used to forbid : export of all symbols of the tarantool executable except a given : list. Motivation of that was to avoid hacking the linker with : false usage of symbols needed to be exported. As a consequence, : symbols not listed in these options became invisible. :=20 : Before these options, when a symbol was defined, but not used in : the final executable, the linker could throw it away, even though : many symbols were used by Lua FFI, or should be visible for user's : dynamic modules. Where the linker, obviously, can't see if they : are needed. :=20 : To make the linker believe the symbols are actually needed there : was a hack with getting pointers at these functions and doing : something with them. :=20 : For example, assume we have 'test()' function in 'box' static : library: :=20 : int : test(void); :=20 : It is not used anywhere in the final executable. So to trick the : linker there is a function 'export_syms()' declared, which takes a : pointer at 'test()' and seemingly does something with it (or : actually does - it does not matter): :=20 : void : export_syms() : { : void *syms[] =3D {test}; : if (time(NULL) =3D=3D 0) { : syms[0](); : syms[1](); : ... : } : } :=20 : Some users want to use not documented but visible symbols, so the : patch removes the dynamic-list option, and returns the linker : hack back. But with 0 dependencies in the export file. :=20 : Closes #2971 :=20 Despite all the future LTO problems we may see, right now it's LGTM Regards, Timur