From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp60.i.mail.ru (smtp60.i.mail.ru [217.69.128.40]) (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 34AA34696C3 for ; Mon, 13 Apr 2020 20:57:38 +0300 (MSK) References: <20200413164435.GX3072@uranus> From: Vladislav Shpilevoy Message-ID: Date: Mon, 13 Apr 2020 19:57:36 +0200 MIME-Version: 1.0 In-Reply-To: <20200413164435.GX3072@uranus> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 00/43] Unhide symbols List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov Cc: tarantool-patches@dev.tarantool.org On 13/04/2020 18:44, Cyrill Gorcunov wrote: > On Mon, Apr 13, 2020 at 04:26:41PM +0200, Vladislav Shpilevoy wrote: >> Another possible improvement I can think of - instead of >> using 'static void *syms[]' everywhere I could make all >> *_export_syms() functions take an argument like >> >> void (*export_f)(void **syms) >> >> And they would pass pointers at their functions there. >> >> The main file, exports.c, would pass here a function, which >> does nothing. Or does panic(), but we will never call these >> _export_syms() functions actually. Will place it under >> something like 'if (time(NULL) == 0)'. >> >> That would allow to turn static arrays into normal arrays on >> the stack and make the executable's size a bit smaller. > > Vladislav, let me summarize the overall idea and the problem: > > 1) Currently tarantool *already* uses extra/exports file during > build procedure, where we keep the list of functions to be > avaliable via Lua ffi interface to the tarantool users. > > While these functions are NOT part of API people relay on them > and use actively, right? In other words they are semi-API I wold > say. Almost correct. Many symbols here are a part of the public API. But some of them are not, and yet it does not mean people use them, at least directly. Non-public symbols are used by Lua FFI, by our own Lua code. So the exported but non-public symbols we can change as we want. Even remove from the export list when they become not needed. Everything else is correct. > 2) Due to our build procedure specifics we link final executable from > static libraries (or archives) and compiler may think that some of > the symbols are not even used and trip them off in optimization > phase. > > 3) Instead of supporting separate extra/exports file we bind symbols > to the source files were they are defined. > > Actually I would prefer more explicit way as I shown you in face > to face talk, but this is definitely not the option for current > timeline. We can try to implement it later. >