Re: non-zero module bias for prelinked ET_EXEC in 0.150

[Roland McGrath <roland at redhat dot com>]

Oy, prelink has too many contorted machinations to keep track of!  I
wasn't aware that it did that one too: juggling the special sections
to move .dynstr after the fixed sections and extending the PT_LOAD
segment to cover it.  That runs afoul of the logic I thought was
going to be right in all cases after my discussion with Jakub about
the original problem.

I've committed a thoroughly untested change that I now think covers
all the bases.  I'd like to consult with Jakub again about all the
potential corners of prelink machination before we declare it really
right, however.  The long comment in the dwfl_module_getdwarf.c change
should explain everything I'm trying to account for now.

We really should add some regression tests to the elfutils tests/
suite to check all the cases.  We haven't added them before for the
past problems because the known cases involved certain real-world
binaries and we really can't include those in the elfutils suite.
To go into elfutils, test binaries need to be reasonably small, and
to be generated only from trivial sources that are all public
domain.  Even if they were small enough (when bzip2'd), using real
binaries is impractical because they are built from GPL'd sources
and so just to include those files would require keeping track of
the sources they came from for pedantic GPL compliance and so forth.
So, we need to put the time in to gin up some representative trivial
binaries that demonstrate the situations that have been problematic.
I'd also like to have ones to cover the other corners I've imagined
but that we have not actually seen occur in real practice yet.

The first step for each case of concern will be to concoct a simple
program from scratch that will be compiled into a form that elicits
prelink to do the changes of concern.  That will take some fiddling
to figure out what contents force prelink into the corners we're
looking for, but it should not be difficult in practice.  Then you
can take each binary and use eu-strip -f to separate a .debug file
form it.

Then take each stripped binary, or a whole set of concocted executables
and DSOs, and run prelink on them individually.  If the system libraries
on your system are already prelinked normally, then an individual
prelink run on a test binary will do the right thing even if it's linked
against normal libraries, so that should not be a problem.  (You can
just ignore the "prelink: Could not write prelink cache" error.)

Then for a test, you can follow the example in tests/run-addrname-test.sh
using 'addr2line -M testmaps'.  Concoct a mapping setup that demonstrates
a permutation you want to test.  For completeness, we should cover both
files being mapped at their prelinked addresses and mapped elsewhere.
The easy thing to do is start with 'cat /proc/<pid>/maps' of a real
process loaded on your system (catch it in gdb at its _start or something),
and then fiddle by hand to represent different variants of mappings.

I think addr2line mapping known addresses to their correct source
locations should be an adequate test, as the run-addrname-test.sh case
using -M we already have does.

That long comment mentions the cases I know off hand to check.  One is
the scenario that you originally found on i686 that led to the 0.150
changes, where REL->RELA conversion in ET_DYN changes the distance from
the beginning of the segment to the real code.  Another is the scenario
you've just found on x86_64, where .gnu_liblist et al insertion in
ET_EXEC changes the distance from the end of the segment to the code.

Next, the theoretical situations.  One is that there is no SHT_PROGBITS
section at all in the first segment, except perhaps for .interp.  That
arises in a binary that has no code, but only some data.  You probably
need -nostartfiles for that ever to actually happen.  If it has some
data initialized to a symbolic address resolved in a DSO it depends on,
then it will have special sections and prelink will want to modify it.
e.g.
	extern int stdin;
	int *fmh = &stdin;
when linked against -lc, or you could gin something up with a DSO you make.
You can't verify against source line information when there is no code.
But perhaps you can do something like give addr2line -S an argument of
'fmh+0' and verify that it resolves the symbol to the right address.

Finally, there is a "fully stripped" binary with no section headers at
all.  That case can't validly be a prelinked case, but we should verify
that we haven't broken it for this case when prelink is not involved.
AFAIK there haven't been any tools (certainly none in common use) that
actually remove the section headers from an ELF file, but it has always
been valid ELF that they could be removed entirely, and there is no real
reason that such a file can't still be matched up with a separate debug
file.  I've just added the --strip-sections option to eu-strip so that
you can use that to generate such cases, i.e.
	eu-strip -f foo.debug --remove-comment --strip-sections foo.bare foo

When he's available, we should also consult with Jakub about what all
other different possibilities there are of how prelink could change
things, and try to produce test cases for all the permutations.


Thanks,
Roland