[Tarantool-patches] [PATCH] cmake: cleanup src/CMakeLists.txt

[Yaroslav Dynnikov]

I've researched the linking process and here is what I've found.

First of all, let's talk about symbols removal. Here is an interesting note
on
how it works:
https://stackoverflow.com/questions/55130965/when-and-why-would-the-c-linker-exclude-unused-symbols
One of the basic important concepts is an ELF section. It's a chunk of data
(assembly code in our case) that linker operates on. A section may contain
code
of one or more functions (depending on build arguments), but it can't be
split
during linking.

Usually, when we build an object file with `gcc libx.c -c -o libx.o`, all
functions from libx.c go into the single ".text" section. This single object
file is usually archived with others into single libx.a, which is later
processed during main executable linking.

By default (but I can't provide the proof), when we call `gcc -lx` linker
operates on object files from the archive - if at least one symbol is used,
whole .o (not .a) is included in the resulting binary. There are also two
linker
options that influence this behavior. At first, there is
`-Wl,--whole-archive`,
which makes it to include whole `.a` instead of `.o` granularity. Secondly,
there is
`-Wl,--gc-sections` which could remove unused sections, but in basic example
it's useless since all symbols from .o belong to the same .text section. To
make
`--gc-sections` have an effect one should compile object files with
`-ffunction-sections` flag. It'll generate a separate section for every
function
so the linker could gc unused ones.

See:
```console$ cat libx.c
#include <stdio.h>

void fA() {
        printf("fA is here\n");
}
void fB() {
        printf("fB is here\n");
}
$ gcc libx.c -c -o libx.o -ffunction-sections
$ readelf -S libx.o | grep .text
  [ 1] .text             PROGBITS         0000000000000000  00000040
  [ 5] .text.fA          PROGBITS         0000000000000000  00000056
  [ 6] .rela.text.fA     RELA             0000000000000000  000002d8
  [ 7] .text.fB          PROGBITS         0000000000000000  0000006d
  [ 8] .rela.text.fB     RELA             0000000000000000  00000308
```

Now let's move to the `libbit` which Vlad mentioned.
I've investigated how compiler options influence the resulting binary.
Unused
functions from bit.c are really remover, but only with Release flags, and
here
is why:

There are only 2 functions implemented in bit.c, and both are unused. All
the
others are inlines in bit.h and externs from luajit. When tarantool is
built in
debug mode, the inlining is off, so other modules truly link to the bit.o
and
all symbols remain including unused functions. But if we specify -O2 flag,
inlining takes place, and all the symbols from bit.o becomes unused, so the
linker drops the whole object file.

Finally, speaking about this patch, my proposal is to merge this PR as is.
And since we know how to manage linking, other problems can be solved
separately
(if they ever occur).

Best regards
Yaroslav Dynnikov

On Thu, 18 Jun 2020 at 02:09, Vladislav Shpilevoy <v.shpilevoy at tarantool.org>
wrote:

> On 17/06/2020 17:29, Mavr Huston wrote:
> >
> > EXPORT_LIST contains following libraries in case of static build (with
> normal build it's empty):
> >
> > /usr/lib/x86_64-linux-gnu/libreadline.so
> >
> > /usr/lib/x86_64-linux-gnu/libcurses.so
> >
> > /usr/lib/x86_64-linux-gnu/libform.so
> >
> > /usr/lib/x86_64-linux-gnu/libtinfo.so
> >
> > /usr/lib/x86_64-linux-gnu/libz.so
> >
> > /opt/local/lib/libssl.so
> >
> > /opt/local/lib/libcrypto.so
> >
> > /usr/lib/x86_64-linux-gnu/libz.so
> >
> > /opt/local/lib/libicui18n.so
> >
> > /opt/local/lib/libicuuc.so
> >
> > /opt/local/lib/libicudata.so
> >
> >
> > It doesn’t contains libcurl because it’s bundled statically. So it isn’t
> related to https://github.com/tarantool/tarantool/issues/4559but this
> problem may be solved with next patch:
> https://github.com/tarantool/tarantool/tree/rosik/refactor-static-build.
> At this patch added flag --disble-symbos-hiding (
> https://github.com/tarantool/tarantool/blob/rosik/refactor-static-build/cmake/BuildLibCURL.cmake#L93)
> at building libcurl and after that most of libcurl symbols are visible from
> tarantool binary
>
> The problem is not in the hiding. It is about removal. Not used symbols
> from
> static libs may be removed from the final executable. Hide or not hide
> rules
> are applied to what is left. That is the single reason why we had exports
> file
> before 2971 and have exports.h and exports.c now. You can try it by
> yourself -
> just add an unused function to lib/bit to bit.h and bit.c. And don't use it
> anywhere. You may even add 'export' to it, or change visibility rules using
> __attribute__ - it does not matter. If the function is not used and is not
> added to exports.h, you won't see it in the executable. (At least it was so
> last time I tried, works not with all libs, but with lib/bit it worked).
>
> Seems EXPORT_LIST was used to extract all symbols from the static libs and
> force their exposure + forbid their removal. Here the symbols were
> retrieved:
>
> https://github.com/tarantool/tarantool/commit/03790ac5510648d1d9648bb2281857a7992d0593#diff-6b9c867c54f1a1b792de45d5262f1dcfL20-L25
>
> Here the libs were passed to mkexports:
>
> https://github.com/tarantool/tarantool/commit/03790ac5510648d1d9648bb2281857a7992d0593#diff-95e351a3805a1dafa85bf20b81d086e6L253-L260
>
> We probably should resurrect that part. Rename the current exports.h to
> exports.h.in
> and generate exports.h during cmake. Like it was done for exports before
> 2971. To
> forbid symbols removal. Not to unhide them.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20200619/32cbfc60/attachment.html>