Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.

[Mark Wielaard]

Hi,

On Tue, 2019-07-02 at 16:21 -0700, Lei Zhang wrote:
> On Tue, Jul 2, 2019 at 4:15 PM Mark Wielaard  wrote:
> > I'll try to create a testcase to replicate the issue to see if I can
> > debug where the offset value gets truncated.
> 
> Sounds good to me.
> 
> > Or do you happen to have the 5.4 GB binary named "chrome" create before
> > splitting still around somewhere where I could download it?
> 
> I still have the file here. I'll send you a link in a separate email.

Thanks for the file, it is indeed pretty big :)
But I am not able to replicate the issue with elfutils from git trunk.
commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0

If I do:
$ export LD_LIBRARY_PATH=/opt/local/install/elfutils/lib
$ /opt/local/install/elfutils/bin/eu-strip \
  -o chrome_elfutil_test.stripped \
  -f chrome_elfutil_test.debug chrome_elfutil_test

then the sections seem to come out correctly:

 36 .debug_info   bb8fa075      0400  2**0
  CONTENTS, READONLY, DEBUGGING
 37 .debug_abbrev 02e97444      bb8fa475  2**0
  CONTENTS, READONLY, DEBUGGING
 38 .debug_aranges 0540      be7918b9  2**0
  CONTENTS, READONLY, DEBUGGING
 39 .debug_line   0a680122      be791df9  2**0
  CONTENTS, READONLY, DEBUGGING
 40 .debug_loc22f253c9      c8e11f1b  2**0
  CONTENTS, READONLY, DEBUGGING
 41 .debug_str3176443a      ebd372e4  2**0
  CONTENTS, READONLY, DEBUGGING
 42 .debug_ranges 053cdc00      11d49b71e  2**0
  CONTENTS, READONLY, DEBUGGING
 43 .debug_macinfo 64fb      12286931e  2**0
  CONTENTS, READONLY, DEBUGGING
 44 .debug_frame  011dfe98      12286f820  2**3
  CONTENTS, READONLY, DEBUGGING
 45 .gdb_index24d27f19      123a4f6b8  2**0
  CONTENTS, READONLY, DEBUGGING

And both the produced chrome_elfutil_test.stripped and
chrome_elfutil_test.debug files seem valid ELF files.

But you might not be using the upstream build system, and you might use
different flags to call it. So, two questions. How did you build your
eu-strip binary? And how do you invoke it?

Thanks,

Mark

Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.

[Lei Zhang]

On Wed, Jul 3, 2019 at 7:53 AM Mark Wielaard  wrote:
> Thanks for the file, it is indeed pretty big :)
> But I am not able to replicate the issue with elfutils from git trunk.
> commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0
>
> And both the produced chrome_elfutil_test.stripped and
> chrome_elfutil_test.debug files seem valid ELF files.

I figured out the problem on my side. The strip binary dynamically
linked to /usr/lib/x86_64-linux-gnu/libelf.so.1 and friends. Once I
set LD_LIBRARY_PATH, I got the expected output.

> But you might not be using the upstream build system, and you might use
> different flags to call it. So, two questions. How did you build your
> eu-strip binary? And how do you invoke it?

I'm building at the same commit on 64-bit Linux:

git clone git://sourceware.org/git/elfutils.git
cd elfutils
autoreconf -i -f
./configure --enable-maintainer-mode
make
make check
cp ./src/strip /path/to/chrome/src/buildtools/third_party/eu-strip/bin/eu-strip

Then I did the build on the Chromium side, which essentially runs:

strip -o chrome.stripped -f chrome.debug chrome

Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.

[Mark Wielaard]

On Wed, 2019-07-03 at 08:23 -0700, Lei Zhang wrote:
> On Wed, Jul 3, 2019 at 7:53 AM Mark Wielaard  wrote:
> > Thanks for the file, it is indeed pretty big :)
> > But I am not able to replicate the issue with elfutils from git
> > trunk.
> > commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0
> > 
> > And both the produced chrome_elfutil_test.stripped and
> > chrome_elfutil_test.debug files seem valid ELF files.
> 
> I figured out the problem on my side. The strip binary dynamically
> linked to /usr/lib/x86_64-linux-gnu/libelf.so.1 and friends. Once I
> set LD_LIBRARY_PATH, I got the expected output.

Great. Thanks for testing on a real world binary.
There aren't actually that many out there this big!
Please do let me know if you still see issues (or discover others).

Thanks,

Mark

Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files.

[Lei Zhang]

On Wed, Jul 3, 2019 at 8:34 AM Mark Wielaard  wrote:
> Great. Thanks for testing on a real world binary.
> There aren't actually that many out there this big!
> Please do let me know if you still see issues (or discover others).

You are welcome. Thank you for fixing this issue in elfutils.

We will probably rebuild our copy of eu-strip from upstream at some
point and stop carrying our own patch. Hopefully there won't be any
issues.

debuginfo server progress update

[Aaron Merey]

Hello,

The debuginfo server, a web service that offers lightweight on-demand lookups
of debuginfo-related data, along with its elfutils client have begun to take
shape so I want to provide an update on where we currently are in its
development and how to use it.

We plan on shipping debuginfo server with elfutils and it is currently
available on the branch 'fche/dbgserver' of the elfutils git repo. The
http web server itself is able to scan a directory tree for any debuginfo,
executable and source files and index them by build-id. The elfutils client
hooks into libdwfl and provides a fallback so that if the library is not able
to locate a debuginfo file, the client, if enabled, will attempt to query
debuginfo servers for debuginfo containing a particular build-id.

As an example, suppose we are trying to trace some program with systemtap.
One of the stap probes we want to run requires DWARF debuginfo but the
executable has been stripped of this information and the corresponding
debuginfo file is not in any of the default directories that stap checks.

$ stap -e 'probe process("/path/to/exec").function("*") { [...] }'
semantic error: while resolving probe point: identifier 'process'
at t.stp:1:7
source: probe process("/path/to/exec").function("*") {
semantic error: no match (similar functions: exit, open,
textdomain, tfind, dup)

Systemtap uses elfutils to locate and read debuginfo files, so it is able
to make use of debuginfo server's elfutils client. First we run debuginfo
server and point it to the directory containing the stripped debuginfo.

$ dbgserver -vvv -p 8002 -F ~/debuginfo_dir &
[Tue Jul  2 15:00:37] (20459/20462): file-path scanning
/home/amerey/debuginfo_dir
[Tue Jul  2 15:00:37] (20459/20459): Started http server on port
8002, database path /home/amerey/.dbgserver.sqlite
[Tue Jul  2 15:00:37] (20459/20462): fts traversing
/home/amerey/debuginfo_dir
[Tue Jul  2 15:00:37] (20459/20462): fts traversing
/home/amerey/debuginfo_dir/debuginfo
[Tue Jul  2 15:00:37] (20459/20462): recorded
buildid=0a0cd15e690a378ec77359bb2eeb76ea0f8d67f8 \
file=/home/amerey/debuginfo_dir/debuginfo mtime=1561060856 as
executable and debuginfo
[...]

In order to enable the elfutils client, there must be a $DBGSERVER_URLS
environment variable containing at least one URL of a debuginfo server
(multiple URLs should be separated by spaces). When we run stap again, elfutils
will query the debuginfo server for debuginfo with the build-id of the
executable.

$ export DBGSERVER_URLS=localhost:8002
$ stap -v -e 'probe process("/path/to/exec").function("*") { [...] }'
[...]
Pass 5: starting run

This time systemtap successfully acquires the debuginfo and begins running
the probe. Although in this example everything is running locally, the server
and the debuginfo could just as well be on a remote host.

Debuginfo server development is ongoing. Some of the features we have planned
include a gdb client that could query debuginfo servers for debuginfo or source
code and the ability for the server to automatically search rpms for any of the
files requested by a client. We also are planning a talk/demo at GNU Cauldron
this September in Montréal, Canada (https://gcc.gnu.org/wiki/cauldron2019).

Hopefully this helped give you a sense of how to use debuginfo server, where it
is in its development, and what is to come. Feedback is always appreciated!

Aaron Merey

[RFC PATCH 1/2] libcpu: merge libcpu_{i386,x86_64,bpf} into one library

[Omar Sandoval]

From: Omar Sandoval 

In preparation for combining the libebl backend modules, combine all of
the libcpu backends into libcpu.a.

Signed-off-by: Omar Sandoval 
---
 backends/ChangeLog   |  4 
 backends/Makefile.am | 12 +++-
 libcpu/ChangeLog |  4 
 libcpu/Makefile.am   | 12 +---
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/backends/ChangeLog b/backends/ChangeLog
index 6c2b47a9..b40a4c8e 100644
--- a/backends/ChangeLog
+++ b/backends/ChangeLog
@@ -1,3 +1,7 @@
+2019-07-02  Omar Sandoval  
+
+   * Makefile.am: Use combined libcpu.a library.
+
 2019-04-14  Mark Wielaard  
 
* riscv_cfi.c: Fix BACKEND define.
diff --git a/backends/Makefile.am b/backends/Makefile.am
index 2126a2ec..0307da07 100644
--- a/backends/Makefile.am
+++ b/backends/Makefile.am
@@ -43,6 +43,7 @@ noinst_LIBRARIES = $(libebl_pic)
 noinst_DATA = $(libebl_pic:_pic.a=.so)
 
 
+libcpu = ../libcpu/libcpu.a
 libelf = ../libelf/libelf.so
 libdw = ../libdw/libdw.so
 libeu = ../lib/libeu.a
@@ -50,7 +51,6 @@ libeu = ../lib/libeu.a
 i386_SRCS = i386_init.c i386_symbol.c i386_corenote.c i386_cfi.c \
i386_retval.c i386_regs.c i386_auxv.c i386_syscall.c \
i386_initreg.c i386_unwind.c
-cpu_i386 = ../libcpu/libcpu_i386.a
 libebl_i386_pic_a_SOURCES = $(i386_SRCS)
 am_libebl_i386_pic_a_OBJECTS = $(i386_SRCS:.c=.os)
 
@@ -61,7 +61,6 @@ am_libebl_sh_pic_a_OBJECTS = $(sh_SRCS:.c=.os)
 x86_64_SRCS = x86_64_init.c x86_64_symbol.c x86_64_corenote.c x86_64_cfi.c \
  x86_64_retval.c x86_64_regs.c i386_auxv.c x86_64_syscall.c \
  x86_64_initreg.c x86_64_unwind.c x32_corenote.c
-cpu_x86_64 = ../libcpu/libcpu_x86_64.a
 libebl_x86_64_pic_a_SOURCES = $(x86_64_SRCS)
 am_libebl_x86_64_pic_a_OBJECTS = $(x86_64_SRCS:.c=.os)
 
@@ -127,7 +126,6 @@ am_libebl_m68k_pic_a_OBJECTS = $(m68k_SRCS:.c=.os)
 m68k_corenote_no_Wpacked_not_aligned = yes
 
 bpf_SRCS = bpf_init.c bpf_regs.c bpf_symbol.c
-cpu_bpf = ../libcpu/libcpu_bpf.a
 libebl_bpf_pic_a_SOURCES = $(bpf_SRCS)
 am_libebl_bpf_pic_a_OBJECTS = $(bpf_SRCS:.c=.os)
 
@@ -137,20 +135,16 @@ libebl_riscv_pic_a_SOURCES = $(riscv_SRCS)
 am_libebl_riscv_pic_a_OBJECTS = $(riscv_SRCS:.c=.os)
 
 
-libebl_%.so libebl_%.map: libebl_%_pic.a $(libelf) $(libdw) $(libeu)
+libebl_%.so libebl_%.map: libebl_%_pic.a $(libcpu) $(libelf) $(libdw) $(libeu)
@rm -f $(@:.so=.map)
$(AM_V_at)echo 'ELFUTILS_$(PACKAGE_VERSION) { global: $*_init; local: 
*; };' \
  > $(@:.so=.map)
$(AM_V_CCLD)$(LINK) $(dso_LDFLAGS) -o $(@:.map=.so) \
-   -Wl,--whole-archive $< $(cpu_$*) -Wl,--no-whole-archive \
+   -Wl,--whole-archive $< $(libcpu) -Wl,--no-whole-archive \
-Wl,--version-script,$(@:.so=.map),--no-undefined \
-Wl,--as-needed $(libelf) $(libdw) $(libeu)
@$(textrel_check)
 
-libebl_i386.so: $(cpu_i386)
-libebl_x86_64.so: $(cpu_x86_64)
-libebl_bpf.so: $(cpu_bpf)
-
 install: install-am install-ebl-modules
 install-ebl-modules:
$(mkinstalldirs) $(DESTDIR)$(libdir)/$(LIBEBL_SUBDIR)
diff --git a/libcpu/ChangeLog b/libcpu/ChangeLog
index adebbef8..0075a793 100644
--- a/libcpu/ChangeLog
+++ b/libcpu/ChangeLog
@@ -1,3 +1,7 @@
+2019-07-02  Omar Sandoval  
+
+   * Makefile.am: Combine backends into libcpu.a.
+
 2018-11-04  Mark Wielaard  
 
* bpf_disasm.c (bpf_disasm): Recognize BPF_JLT, BPF_JLE, BPF_JSLT
diff --git a/libcpu/Makefile.am b/libcpu/Makefile.am
index 4c8778d1..a7d9f6fd 100644
--- a/libcpu/Makefile.am
+++ b/libcpu/Makefile.am
@@ -35,20 +35,16 @@ LEXCOMPILE = $(LEX) $(LFLAGS) $(AM_LFLAGS) -P$( $@T
$(AM_V_at)mv -f $@T $@
@@ -86,6 +82,8 @@ i386_gendis_LDADD = $(libeu) -lm
 
 i386_parse.h: i386_parse.c ;
 
+bpf_disasm_CFLAGS = -Wno-format-nonliteral
+
 EXTRA_DIST = defs/i386
 
 CLEANFILES += $(foreach P,i386 x86_64,$P_defs $P.mnemonics)
-- 
2.22.0

[RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

[Omar Sandoval]

From: Omar Sandoval 

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

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

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

[RFC PATCH 2/2] Don't use dlopen() for libebl modules

[Omar Sandoval]

From: Omar Sandoval 

Currently, architecture-specific code for libebl exists in separate
libebl_$ARCH.so libraries which libebl loads with dlopen() at runtime.
This makes it impossible to have standalone, statically-linked binaries
which use libdwfl if they depend on any architecture-specific
functionality. Additionally, when these libraries cannot be found, the
failure modes are non-obvious. So, let's get rid of libebl_$arch.so and
move it all into libebl.a, which simplifies things considerably.

Signed-off-by: Omar Sandoval 
---
 ChangeLog|   6 +
 Makefile.am  |   4 +-
 backends/ChangeLog   |   1 +
 backends/Makefile.am |  93 ++
 configure.ac |  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 +-
 17 files changed, 195 insertions(+), 299 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5c45cccf..ff12ee27 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2019-07-02  Omar Sandoval  
+
+   * configure.ac: Get rid of --enable-libebl-subdir.
+   * Makefile.am: Reorder backends and libcpu before libebl in SUBDIRS to
+   satisfy build dependencies.
+
 2019-02-14  Mark Wielaard  
 
* configure.ac: Set version to 0.176.
diff --git a/Makefile.am b/Makefile.am
index 2ff444e7..51f54552 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -27,8 +27,8 @@ AM_MAKEFLAGS = --no-print-directory
 pkginclude_HEADERS = version.h
 
 # Add doc back when we have some real content.
-SUBDIRS = config m4 lib libelf libebl libdwelf libdwfl libdw libcpu libasm \
- backends src po tests
+SUBDIRS = config m4 lib libelf libcpu backends libebl libdwelf libdwfl libdw \
+ libasm src po tests
 
 EXTRA_DIST = elfutils.spec GPG-KEY NOTES CONTRIBUTING \
 COPYING COPYING-GPLV2 COPYING-LGPLV3
diff --git a/backends/ChangeLog b/backends/ChangeLog
index b40a4c8e..11f513c1 100644
--- a/backends/ChangeLog
+++ b/backends/ChangeLog
@@ -1,6 +1,7 @@
 2019-07-02  Omar Sandoval  
 
* Makefile.am: Use combined libcpu.a library.
+   Combine modules into libebl_backends.a.
 
 2019-04-14  Mark Wielaard  
 
diff --git a/backends/Makefile.am b/backends/Makefile.am
index 0307da07..733c8623 100644
--- a/backends/Makefile.am
+++ b/backends/Makefile.am
@@ -28,95 +28,58 @@
 ## the GNU Lesser General Public License along with this program.  If
 ## not, see .
 include $(top_srcdir)/config/eu.am
+AM_CFLAGS += $(fpic_CFLAGS)
 AM_CPPFLAGS += -I$(top_srcdir)/libebl -I$(top_srcdir)/libasm \
   -I$(top_srcdir)/libelf -I$(top_srcdir)/libdw
 
+noinst_LIBRARIES = libebl_backends.a
 
 modules = i386 sh x86_64 ia64 alpha arm aarch64 sparc ppc ppc64 s390 \
  tilegx m68k bpf riscv
-libebl_pic = libebl_i386_pic.a libebl_sh_pic.a libebl_x86_64_pic.a\
-libebl_ia64_pic.a libebl_alpha_pic.a libebl_arm_pic.a\
-libebl_aarch64_pic.a libebl_sparc_pic.a libebl_ppc_pic.a \
-libebl_ppc64_pic.a libebl_s390_pic.a libebl_tilegx_pic.a \
-libebl_m68k_pic.a libebl_bpf_pic.a libebl_riscv_pic.a
-noinst_LIBRARIES = $(libebl_pic)
-noinst_DATA = $(libebl_pic:_pic.a=.so)
-
-
-libcpu = ../libcpu/libcpu.a
-libelf = ../libelf/libelf.so
-libdw = ../libdw/libdw.so
-libeu = ../lib/libeu.a
 
 i386_SRCS = i386_init.c i386_symbol.c i386_corenote.c i386_cfi.c \
i386_retval.c i386_regs.c i386_auxv.c i386_syscall.c \
i386_initreg.c i386_unwind.c
-libebl_i386_pic_a_SOURCES = $(i386_SRCS)
-am_libebl_i386_pic_a_OBJECTS = $(i386_SRCS:.c=.os)
 
 sh_SRCS = sh_init.c sh_symbol.c sh_corenote.c sh_regs.c sh_retval.c
-libebl_sh_pic_a_SOURCES = $(sh_SRCS)
-am_libebl_sh_pic_a_OBJECTS = $(sh_SRCS:.c=.os)
 
 x86_64_SRCS = x86_64_init.c x86_64_symbol.c x86_64_corenote.c x86_64_cfi.c \
- x86_64_retval.c x86_64_regs.c i386_auxv.c x86_64_syscall.c \
- x86_64_initreg.c x86_64_unwind.c x32_corenote.c
-libebl_x86_64_pic_a_SOURCES = $(x86_64_SRCS)
-am_libebl_x86_64_pic_a_OBJECTS = $(x86_64_SRCS:.c=.os)
+ x86_64_retval.c x86_64_regs.c x86_64_syscall.c x86_64_initreg.c \
+ x86_64_unwind.c x32_corenote.c
+
 
 ia64_SRCS = ia64_init.c ia64_symbol.c ia64_regs.c ia64_retval.c
-libebl_ia64_pic_a_SOURCES = $(ia64_SRCS)
-am_libebl_ia64_pic_a_OBJECTS = $(ia64_SRCS:.c=.os)
 
 alpha_SRCS = alpha_init.c alpha_symbol.c alpha_retval.c alpha_regs.c \
 alpha_corenote.c alpha_auxv.c
-libebl_alpha_pic_a_SOURCES = $(alpha_SRCS)
-am_libebl_alpha_pic_a_OBJECTS = $(alpha_SRCS:.c=.os)
 
 arm_SRCS = arm_init.c arm_symbol.c arm_regs.c arm_corenote.c \
 

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

[Frank Ch. Eigler]

Hi -

> [...]
> 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
> 56K ./src/objdump
> 
> Static backends (after this series):
> 44K ./libasm/libasm.so
> 668K./libdw/libdw.so
> 120K./libelf/libelf.so
> 348K./src/objdump

Assuming a dynamically linked objdump would be the same size as
before, and that the libebl-* contents would only bloat libdw.so,
and only by 300K, IMHO we should just go for it.


- FChE

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

[Omar Sandoval]

On Wed, Jul 03, 2019 at 05:33:42PM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> > [...]
> > 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
> > 56K ./src/objdump
> > 
> > Static backends (after this series):
> > 44K ./libasm/libasm.so
> > 668K./libdw/libdw.so
> > 120K./libelf/libelf.so
> > 348K./src/objdump
> 
> Assuming a dynamically linked objdump would be the same size as
> before, and that the libebl-* contents would only bloat libdw.so,
> and only by 300K, IMHO we should just go for it.

This is actually with dynamically linked binaries -- the size increase
is because we link libebl.a directly into all of the binaries in
addition to libdw.so:

objdump_LDADD  = $(libasm) $(libebl) $(libdw) $(libelf) $(libeu) $(argp_LDADD)

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

[Frank Ch. Eigler]

Hi - 

> This is actually with dynamically linked binaries -- the size increase
> is because we link libebl.a directly into all of the binaries in
> addition to libdw.so:
> 
> objdump_LDADD  = $(libasm) $(libebl) $(libdw) $(libelf) $(libeu) $(argp_LDADD

Is there some reason to keep doing that?

- FChE

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

[Omar Sandoval]

On Wed, Jul 03, 2019 at 05:39:53PM -0400, Frank Ch. Eigler wrote:
> Hi - 
> 
> > This is actually with dynamically linked binaries -- the size increase
> > is because we link libebl.a directly into all of the binaries in
> > addition to libdw.so:
> > 
> > objdump_LDADD  = $(libasm) $(libebl) $(libdw) $(libelf) $(libeu) 
> > $(argp_LDADD
> 
> Is there some reason to keep doing that?
> 
> - FChE

Yes:

$ make -C src
make: Entering directory '/home/osandov/dev/elfutils/src'
  CCLD objdump
/bin/ld: objdump.o: in function `show_relocs_x':
/home/osandov/dev/elfutils/src/objdump.c:352: undefined reference to 
`ebl_reloc_type_name'
/bin/ld: objdump.o: in function `handle_elf':
/home/osandov/dev/elfutils/src/objdump.c:755: undefined reference to 
`ebl_openbackend'
/bin/ld: /home/osandov/dev/elfutils/src/objdump.c:757: undefined reference to 
`ebl_backend_name'
/bin/ld: /home/osandov/dev/elfutils/src/objdump.c:788: undefined reference to 
`ebl_closebackend'
collect2: error: ld returned 1 exit status
make: *** [Makefile:624: objdump] Error 1
make: Leaving directory '/home/osandov/dev/elfutils/src'

Some of the binaries use libebl, and although libebl is linked into libdw.so,
the libebl symbols are not exported by libdw. So, libebl is linked in
statically for the binaries.

This is why I suggested exporting those symbols from libdw.so. (I also
considered adding a libebl.so, but that would have a circular dependency with
libdw.so, so they might as well be combined).

Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules

[Frank Ch. Eigler]

Hi -

> Some of the binaries use libebl, and although libebl is linked into libdw.so,
> the libebl symbols are not exported by libdw. So, libebl is linked in
> statically for the binaries.
> 
> This is why I suggested exporting those symbols from libdw.so. (I also
> considered adding a libebl.so, but that would have a circular dependency with
> libdw.so, so they might as well be combined).

Ah, thanks for the (re-)explanation.  IMHO, if the API is useful
enough to be used by mainline elfutils binaries, it is useful enough
to be used by others.  So a +1 from me for solib-exporting them.

- FChE