Hi Mark, On Tue, Nov 14, 2023 at 9:03 AM Mark Wielaard <m...@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
