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

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

>> On 15 Apr 2020, at 13:40, Mons Anderson <mons@cpan.org> wrote:
>>
>> On Tue, Apr 14, 2020 at 11:41 PM Konstantin Osipov
>> <kostja.osipov@gmail.com> wrote:
>>>
>>> * Timur Safin <tsafin@tarantool.org> [20/04/14 21:01]:
>>>> : Mons will be happy simply if we switch back to default gcc linking
>>>> : options, -fvisibility=default, which is basically dropping
>>>> : -exported_symbols_list.
>>
>> We've been discussing this with team. It is sufficient for me.
>> But you can't just drop exported_symbols_list without replacing it
>> with something else to guarantee presence of internal ffi functions
>>
> This could be done with approach from @cyrillos, AFAIU. These functions
> should be annotated in the code, rather than collected in a separate 
> list.

Yeah, the problem is that there is no a compiler option, which would
prevent removal of certain unused symbols defined in static libraries,
when they are merged into one executable.

You can either export all of them using whole-archive option, or
export a list via the option used on the master branch now (but that
masks out all other symbols).

Cyrill G. was referring to a kernel EXPORT_API macros. The problem is
it has nothing to do with compiler attributes. That macros generates a
special section for every function in assembly with a prefix __ksymtab
or something like that. That section contains the original symbol
reference + some meta.

https://github.com/torvalds/linux/blob/master/include/linux/export.h#L97

Then all such sections having the same prefix are merged into one big
section here:

https://github.com/torvalds/linux/blob/master/scripts/module-common.lds

And exported via a global array here:

https://github.com/torvalds/linux/blob/master/kernel/module.c#L379

So essentially this is the same what I am doing, but using some assembly
and a linker script.

Timur and Cyrill can correct me if I am wrong somewhere above.

I would happy to implement something like that but looks like it is
not worth the complexity.

> If a function is not present in the tarantool binary - e.g. 
> dropped as not used from static library - it should not be available 
> anyways. Will it work you, Mons?

All our public C API functions are defined in static libraries, and
many of them are not used in the executable nor used by FFI. And
still they should be available for dynamic user modules (.so, .dylib).