Hi Omar,
On Tue, 2019-07-09 at 12:25 -0700, Omar Sandoval wrote:
> On Tue, Jul 09, 2019 at 09:14:03PM +0200, Mark Wielaard wrote:
> > Then after the release, somewhere next week, we'll apply your patches
> > first and can then deal with any fallout and followups. I am thinking
> > of moving some o
On Tue, Jul 09, 2019 at 09:14:03PM +0200, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-07-08 at 14:02 -0700, Omar Sandoval wrote:
> > I imagine that little by little, most of the libebl functionality could
> > be converted in this way, and that's how we could chip away at the size
> > increase
Hi Omar,
On Mon, 2019-07-08 at 14:02 -0700, Omar Sandoval wrote:
> I imagine that little by little, most of the libebl functionality could
> be converted in this way, and that's how we could chip away at the size
> increase of the elfutils binaries.
>
> Do you have any objections to patches 1-4 o
* Omar Sandoval:
> This makes sense. One thing I noted in the patch to export the libebl
> symbols [1] is that exporting them wouldn't necessarily mean supporting
> them as an official API. However, I can see why you'd be concerned with
> developers using them anyways.
You could ship a link-only
On Mon, Jul 08, 2019 at 10:48:52PM +0200, Mark Wielaard wrote:
> On Wed, 2019-07-03 at 20:56 -0400, Frank Ch. Eigler wrote:
> > > 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
> > > st
On Wed, 2019-07-03 at 20:56 -0400, Frank Ch. Eigler wrote:
> > 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 tho
Hi Omar,
On Wed, 2019-07-03 at 13:03 -0700, Omar Sandoval wrote:
> 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 sile
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
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 -
> 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: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 -
> [...]
> 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
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
13 matches
Mail list logo
