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

2019-07-03 Thread 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, b

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

2019-07-03 Thread 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) $(libd

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

2019-07-03 Thread 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? -

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

2019-07-03 Thread 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

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

2019-07-03 Thread 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/l

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

2019-07-03 Thread 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 func

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

2019-07-03 Thread 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 libeb

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

2019-07-03 Thread 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

debuginfo server progress update

2019-07-03 Thread 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 serv

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

2019-07-03 Thread 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 wil

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

2019-07-03 Thread 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 > > > >

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

2019-07-03 Thread 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_elfut

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

2019-07-03 Thread 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 G