[Tarantool-patches] [PATCH 00/43] Unhide symbols
Cyrill Gorcunov
gorcunov at gmail.com
Thu Apr 16 15:13:50 MSK 2020
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
More information about the Tarantool-patches
mailing list