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
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
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
> >
> >
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
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
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
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
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
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
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
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?
-
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
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
13 matches
Mail list logo
