search

genodelabs / goa

Tool for streamlining the development of Genode applications
GNU Affero General Public License v3.0
19 stars 18 forks source link

Goa-generated shared libraries are huge #60

Closed jschlatow closed 10 months ago

jschlatow commented 1 year ago

I just noticed that the lib.so files generated by Goa are all ~17MB large. This also holds for the cmake_library example. I found that the -Wl,-Ttext=0x1000000 argument is passed as ldflags to cmake also for shared libraries, which inflates the resulting file by 16MB.

jschlatow commented 1 year ago

I naively tried removing the -Ttext flag from the ldflags passed to cmake as CMAKE_SHARED_LINKER_FLAGS (see commit 6e2f622). This seemed to work when building libraries. However, this triggers a build error in a dependent library:

[lvgl_support:cmake] /usr/bin/cmake -E cmake_link_script CMakeFiles/lvgl_support.dir/link.txt --verbose=1
[lvgl_support:cmake] /usr/local/genode/tool/21.05/bin/genode-x86-g++ -fPIC -fPIC -O2 -D__GENODE__ -m64 -Wall -Wextra -Weffc++ -Werror -Wsuggest-override -fno-strict-aliasing -nostdinc -D__BSD_VISIBLE -D__FreeBSD__=8 -I/home/johannes/repos/genode/depot/genodelabs/api/base/2023-04-25/include/spec/x86_64 -I/home/johannes/repos/genode/depot/genodelabs/api/base/2023-04-25/include/spec/x86 -I/home/johannes/repos/genode/depot/genodelabs/api/base/2023-04-25/include/spec/64bit -I/home/johannes/repos/genode/depot/genodelabs/api/base/2023-04-25/include -I/home/johannes/repos/genode/depot/genodelabs/api/os/2023-04-16/include/spec/x86_64 -I/home/johannes/repos/genode/depot/genodelabs/api/os/2023-04-16/include -I/home/johannes/repos/genode/depot/genodelabs/api/gui_session/2023-03-12/include -I/home/johannes/repos/genode/depot/genodelabs/api/framebuffer_session/2023-03-12/include -I/home/johannes/repos/genode/depot/genodelabs/api/input_session/2023-03-12/include -I/home/johannes/repos/genode/depot/genodelabs/api/stdcxx/2022-04-27/include/spec/x86_64 -I/home/johannes/repos/genode/depot/genodelabs/api/stdcxx/2022-04-27/include -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include/spec/x86_64 -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include/spec/x86 -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include -I/home/johannes/repos/genode/depot/tmp/api/lvgl/2023-06-28/include -I/usr/local/genode/tool/21.05/lib/gcc/x86_64-pc-elf/10.3.0/include -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include/libc -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include/libc-genode -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include/spec/x86/libc -I/home/johannes/repos/genode/depot/genodelabs/api/libc/2023-01-23/include/spec/x86_64/libc -I/home/johannes/repos/genode/depot/genodelabs/api/stdcxx/2022-04-27/include/stdcxx -I/home/johannes/repos/genode/depot/genodelabs/api/stdcxx/2022-04-27/include/stdcxx/std -I/home/johannes/repos/genode/depot/genodelabs/api/stdcxx/2022-04-27/include/stdcxx/c_global -I/home/johannes/repos/genode/depot/genodelabs/api/stdcxx/2022-04-27/include/spec/x86_64/stdcxx -Wl,-gc-sections -Wl,-z -Wl,max-page-size=0x1000 -Wl,--eh-frame-hdr -Wl,-rpath-link=. -Wl,-melf_x86_64 -nostartfiles -nodefaultlibs -static-libgcc -L/home/johannes/repos/goa-pkgs/var/projects/lvgl_support/abi/x86_64 -lgcc -Wl,-shared -l:ldso_so_support.lib.a -T /home/vali/repos/goa/share/goa/ld/genode_rel.ld -l:stdcxx.lib.so -l:libc.lib.so -l:libm.lib.so -l:posix.lib.so -l:liblvgl_demos.lib.so -l:liblvgl.lib.so -shared  -o liblvgl_support.lib.so CMakeFiles/lvgl_support.dir/lvgl_support.cc.obj 
/usr/local/genode/tool/21.05/bin/../lib/gcc/x86_64-pc-elf/10.3.0/../../../../x86_64-pc-elf/bin/ld: CMakeFiles/lvgl_support.dir/lvgl_support.cc.obj: in function `Lvgl::init(Genode::Env&, Lvgl::Config)':
lvgl_support.cc:(.text+0x101c): undefined reference to `__dso_handle'
/usr/local/genode/tool/21.05/bin/../lib/gcc/x86_64-pc-elf/10.3.0/../../../../x86_64-pc-elf/bin/ld: CMakeFiles/lvgl_support.dir/lvgl_support.cc.obj: relocation R_X86_64_PC32 against undefined hidden symbol `__dso_handle' can not be used when making a shared object

@ssumpf Since this is not my area of expertise, I was wondering whether you'd like to look into this?

chelmuth commented 1 year ago

This reminds me of genodelabs/genode@3f6b95ca3a5ca126d1235caa0c760734c34a5e8a...

In your case, -l:ldso_so_support.lib.a should provide the symbol, but maybe we should declare __dso_handle in genode_rel.ld as in genode.ld and genode_dyn.ld?

jschlatow commented 1 year ago

In your case, -l:ldso_so_support.lib.a should provide the symbol

This is what I was thinking as well but -l:ldso_so_support.lib.a is already part of the g++ arguments. The library is also present in the project's abi directory.

cproc commented 1 year ago

This is what I was thinking as well but -l:ldso_so_support.lib.a is already part of the g++ arguments. The library is also present in the project's abi directory.

Does it work if -l:ldso_so_support.lib.a is moved more to the end of the link command line or if all library arguments are enclosed within -Wl,--start-group and -Wl,--end-group?

ssumpf commented 1 year ago

@jschlatow: I can have a look as well.

ssumpf commented 1 year ago

This reminds me of genodelabs/genode@3f6b95c...

In your case, -l:ldso_so_support.lib.a should provide the symbol, but maybe we should declare __dso_handle in _genoderel.ld as in genode.ld and _genodedyn.ld?

I am also for this. __dso_handle is needed for global destructors in shared objects, we do not use it at all. It it should be sufficient to declare it in _genoderel.ld. I will have a look of why -l:ldso_so_support.lib.a does not work.

ssumpf commented 1 year ago

@jschlatow: Could you publish your jschlatow/api/lvgl so I have something to test quickly?

ssumpf commented 1 year ago

@jschlatow: Could you publish your jschlatow/api/lvgl so I have something to test quickly?

Never mind, I was able to publish it myself.

ssumpf commented 1 year ago

After trying out some things I came to the conclusion that putting -l:ldso_so_support.lib.a into --whole-archive is the safest option. After some tests I found that --nostartfiles causes the removal of __dso_handle as well as the .ctor section and the corresponding .init section that contains the function that actually calls the ctors. This might be the case because the library does not contain any global constructors. Unfortunately, I don't have a test library at hand to see if .ctors and .init re-appear when there are definitely global constructors present. Therefore, lets play it safe (11b3626). This also implies that adding __dso_handle__ to _genoderel.ld (which we still should do) only fixes a part of the problem.

ssumpf commented 1 year ago

Followup: I have added - as a test - a global constructor to _liblvglsupport.lib.so and added __dso_handle to _genoderel.ld. This lead to a .ctor section of size 8 (no start and end markers) and no .init section in _liblvglsupport.lib.so, meaning the ctors will not be called (=broken). So 11b3626 seems to be the way to go.

chelmuth commented 1 year ago

@ssumpf Would you mind to still craft a commit to move the __dso_handle from base/src/lib/ldso/so_support.c to genode_rel.ld?

ssumpf commented 1 year ago

@ssumpf Would you mind to still craft a commit to move the __dso_handle from _base/src/lib/ldso/sosupport.c to _genoderel.ld?

On second thought, I am not really up it because if there is no undefined reference to __dso_handle, we will not notice that there is not .init section and only notice later once the .ctors are not called. If we use the lib and __dso_handle is in the lib, we also know .init is there.

jschlatow commented 11 months ago

@ssumpf Thanks for the fix. I merged your commit to staging as fda9e7b.