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

[Cyrill Gorcunov <gorcunov@gmail.com>]

On Wed, Apr 15, 2020 at 11:58:06PM +0200, Vladislav Shpilevoy wrote:
> >>
> > 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.

Actually no, if symbols are reffered in executable they won't be vanished.
Accessing symbols should be done in transparent way. IOW, I think of
similar to kernel approach:

 - provide EXPORT_SYMBOL helper (macro which would put it into a section)
 - generate a special bootstrap routine which would access the cummulative
   symbols in the gathered section (linker must not drop it I think)

But this is only ideas which I didn't dive into technical details yet
and I refuse to do it in a rush! If this symbols are really that needed
then Vladislav approach should do the trick and we could switch to another
sheme transparently.

> 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

Not for every, only for those which are market with EXPORT_SYMBOL[_x]

> or something like that. That section contains the original symbol
> reference + some meta.

The meta actually is the virtual address and it is needed the kernel
would test checksum on start to be sure that we're not corrupted.

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

Yup, correct.

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

As to me this is a way better in long term than current approach.
I like to see immediately that some symbol is exported instead of
stepping into extra/exports or whatever.

But again, as I said I hate to do it in a rush and any scheme you
provide now is ok for me sice we can change it transparently if we will.

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

	Cyrill