Re: [PATCH] libdwfl: Correctly handle corefile non-contiguous segments

[Aaron Merey <amerey@redhat.com>]

Hi Mark,

On Tue, Nov 14, 2023 at 9:03 AM Mark Wielaard <mark@klomp.org> wrote:
>
> > A couple caveats should be mentioned.  First, start and end addresses
> > of reported modules cannot be assumed to contain segments from only
> > that module.  This has always been the case however.
>
> There is dwfl_addrmodule/dwfl_addrsegment to find the module that
> covers a specific address. Defined in libdwfl/segment.c. I think this
> should handle this by checking the closes load address. But I have not
> tested it.
>
> Normally only kernel modules (.ko ET_REL files) have multiple segments.
> So it might make sense to double check none of this impacts systemtap.

I'll look into this.

> > Second, the testcases in this patch use a firefox corefile that is
> > fairly large.  The .bz2 corefile is about 47M.  A clean elfutils repo
> > is currently about 42M, so this corefile more than doubles the size of
> > the elfutils repo.  I looked for a much smaller process with
> > interleaving non-contiguous shared library sections but was not able
> > to find one.  I've included the corefile and tests in this patch but
> > they can be removed if we'd prefer to not approx. double the size of
> > the repo.
>
> I really appreciate the testcase, but it really is too big. It is 736M
> bunzip2ed (which would happen on any make check). I think this makes
> the repo and the build/check a little too heavy. Also we try to include
> instructions to recreate any binary test files and that isn't really
> possible in this case.

Agreed, this isn't a great testcase.  I'm not sure if there's a way to
force the linker to create segments that reproduce the bug on a much
smaller process, but I'll see if I can write something by hand with
libelf.  Or maybe GNU poke can be of use here?  I'll take a look.

Aaron