Re: [patch] bfd_elf_bfd_from_remote_memory() workaround for the ELF misalignment [Re: loadbase alignment - ld.so/prelink/kernel or bfd_elf_bfd_from_remote_memory() bug?]

[Roland McGrath <roland at redhat dot com>]

> What practical consequence does it have to use a too small value here?
[...]
> We're trying to create an _ELF file_ from memory, not a loaded image.
> We only need the bits that would have been in the file!

That's precisely the issue.  The actual page size used by the process in
question is what tells you the true facts about how much of the original
ELF file is in the memory that you can read now.

The page alignment probably doesn't come up in practice for getting the
beginning of the file, because even without it you are usually sure from
phdr arithmetic what vaddr corresponds to file offset 0.  It is relevant
in practice to finding the end of the file.  

The only case where this function is used today is the Linux vDSO.  That
is a DSO with one segment, or two segments that are both read-only and
map the same part of the file (IA64).  The part of the file after the
p_vaddr+p_filesz (=p_memsz) of the last segment will be in the memory
image, up to the next page boundary.  This is where the section headers
and .shstrtab reside (or other nonallocated sections for an unstripped
file, but this is not the case with the vDSO).  Of course, the zeros seen
in memory for the tail of the page past the end of the file are not part
of the file, so it misrepresents the original file to just always include
the whole last page.  Hence the function has the special heuristic to
truncate to the shorter of the file portion available in memory and the
offset at the end of the section headers as indicated by the ELF header.

It is pleasant to have the section headers and names when they are
available.  At least at some point in the past, I think it may have been
required for gdb to find everything it should, because it didn't find
everything from PT_GNU_EH_FRAME, PT_DYNAMIC, DT_*, etc.  (I don't know if
that is an issue with today's code.)

It so happens that in all the Linux vDSO images today, there is enough of
the partial page after the segments to include all the section headers.
(In point of fact, the way Linux loads the vDSO is just a flat mapping of
the whole file, not driven by its phdrs.  So, for example, as things
stand if the ppc/ppc64 vDSO grew so its segments exactly filled out n
pages, an n+1'th page of .shstrtab and section headers would be there in
memory.  But there is no way to determine this from a dump/process, short
of assuming it as a special case for the vDSO that the maximum size the
ELF header suggests will in fact be there.)

This is the only case used by gdb today.  There is another case relevant
to my thinking, that I do support in the equivalent code in the elfutils
libraries.  A normal DSO usually has a data segment with some bss,
i.e. p_memsz > p_filesz.  In that case, the end of the file is never
available in memory.  The part of the file you can get intact (or close)
from memory is truncated at the p_filesz of the data segment.  But, you
can usually see the whole text segment, which includes .eh_frame and for
DSOs includes the dynamic symbol table.  So, it really is worthwhile to
get as much as you can get, and you do need to know the page size to
reliably know what you can get.  (This is probably only of interest when
dealing with core dumps when using the option to dump all segments in
their entirety rather than suppressing text segments as usual.)


Thanks,
Roland