From: Omar Sandoval <osan...@fb.com> Hi,
I'm developing an application which uses libdwfl. When I tested it in our production environment, the application hit DWARF parsing errors for Linux kernel modules. I tracked it down to an issue that ELF relocations were silently not being applied because the proper libebl_CPU.so could not be found. That appears to be a bug in relocate_sections() or check_badreltype() in libdwfl, but that got me looking at getting rid of the dlopen() entirely. IMO, it simplifies things nicely, and it makes it possible to use the elfutils libraries in standalone static binaries. I came across a previous discussion [1] where Mark suggested a hybrid approach, where one could configure which modules to compile in and which ones to keep separate. I tried to implement this, but it quickly turned into automake dependency hell: the backends subdirectory needs to depend on the libdw subdirectory in order to link libebl_CPU.so against libdw.so, but the libdw subdirectory needs to depend on the backends subdirectory in order to include the static backends in libdw.so. My understanding of the benefit of separate modules is that we don't need to link all backend modules into every elfutils binary. I did some measurements to that end: Dynamic backends (status quo): 44K ./libasm/libasm.so 380K ./libdw/libdw.so 120K ./libelf/libelf.so 72K ./src/nm 28K ./src/size 80K ./src/strip 140K ./src/elflint 28K ./src/findtextrel 36K ./src/addr2line 52K ./src/elfcmp 56K ./src/objdump 32K ./src/strings 48K ./src/ar 60K ./src/unstrip 36K ./src/stack 40K ./src/elfcompress 32K ./src/ranlib 272K ./src/readelf 68K backends/libebl_i386.so 24K backends/libebl_sh.so 76K backends/libebl_x86_64.so 28K backends/libebl_ia64.so 24K backends/libebl_alpha.so 36K backends/libebl_arm.so 44K backends/libebl_aarch64.so 36K backends/libebl_sparc.so 36K backends/libebl_ppc.so 36K backends/libebl_ppc64.so 32K backends/libebl_s390.so 24K backends/libebl_tilegx.so 20K backends/libebl_m68k.so 24K backends/libebl_bpf.so 32K backends/libebl_riscv.so 2.1M total Static backends (after this series): 44K ./libasm/libasm.so 668K ./libdw/libdw.so 120K ./libelf/libelf.so 356K ./src/nm 28K ./src/size 368K ./src/strip 428K ./src/elflint 28K ./src/findtextrel 36K ./src/addr2line 340K ./src/elfcmp 348K ./src/objdump 32K ./src/strings 48K ./src/ar 60K ./src/unstrip 36K ./src/stack 40K ./src/elfcompress 32K ./src/ranlib 560K ./src/readelf 3.5M total If the size increase is a deal-breaker, one easy solution may be to export the libebl symbols from libdw so that libebl.a doesn't need to be linked into the elfutils binaries. Considering that libebl.a is already shipped by distributions, this doesn't increase the surface area of exported APIs (and the warning in libebl.h should make it clear that these APIs are not intended to be used). Thoughts? Is the size increase palatable? Should I add a third patch to export the libebl symbols in libdw in order to mitigate the size increase? Or is this a dead end? Thanks! 1: https://sourceware.org/ml/elfutils-devel/2018-q2/msg00171.html Omar Sandoval (2): libcpu: merge libcpu_{i386,x86_64,bpf} into one library Don't use dlopen() for libebl modules ChangeLog | 6 + Makefile.am | 4 +- backends/ChangeLog | 5 + backends/Makefile.am | 99 ++------------- configure.ac | 12 +- libcpu/ChangeLog | 4 + libcpu/Makefile.am | 12 +- libdw/ChangeLog | 7 + libdw/Makefile.am | 11 +- libebl/ChangeLog | 11 ++ libebl/Makefile.am | 7 +- libebl/eblclosebackend.c | 4 - libebl/eblopenbackend.c | 267 +++++++++++++++------------------------ libebl/libeblP.h | 3 - src/ChangeLog | 7 + src/Makefile.am | 18 +-- tests/ChangeLog | 5 + tests/Makefile.am | 34 ++--- tests/test-subr.sh | 4 +- 19 files changed, 208 insertions(+), 312 deletions(-) -- 2.22.0
