[Tarantool-patches] [PATCH 00/43] Unhide symbols

[Vladislav Shpilevoy]

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.
>