From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4C54B4696C3 for ; Mon, 13 Apr 2020 19:44:38 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id r7so9350632ljg.13 for ; Mon, 13 Apr 2020 09:44:38 -0700 (PDT) Date: Mon, 13 Apr 2020 19:44:35 +0300 From: Cyrill Gorcunov Message-ID: <20200413164435.GX3072@uranus> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org 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. 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.