Problem with D_PAGED handling for ELF
Daniel Jacobowitz
drow@false.org
Tue Jan 25 21:46:00 GMT 2005
I was handed an interesting bug where objcopy caused corruption of the
program headers for a binary produced by a third party toolchain. The VMAs
and alignments got eaten. After a lot of banging my head on the ground, I
discovered that this happened because the producing toolchain differed from
binutils on its opinion of the page size.
Here's how BFD verifies that a binary is "usefully" dynamic paged:
/* If the section is loaded, but not page aligned, clear
D_PAGED. */
if (i_shdrp[shindex].sh_size != 0
&& (i_shdrp[shindex].sh_flags & SHF_ALLOC) != 0
&& i_shdrp[shindex].sh_type != SHT_NOBITS
&& (((i_shdrp[shindex].sh_addr - i_shdrp[shindex].sh_offset)
% ebd->maxpagesize)
!= 0))
abfd->flags &= ~D_PAGED;
The problem is, binutils was configured to generate binaries that would work
on any page size up to 64k, and the third party toolchain was configured to
generate binaries that would work on a particular system where the toolchain
was known to be 4k. So it only aligned the segments to 4k.
There's two plausible solutions I can see for this:
- Add a "minimum page size" to the ELF backend, and use that instead for
this check. Generate binaries that will work up to MAX, accept binaries
designed for at least MIN.
- Disable the check entirely. Assume any ELF binary with program headers
is demand paged. I am not sure about the consequences of this.
(I tried working around it by just "fixing" the page size. Unfortunately,
the target systems have configurable page sizes, and I don't have a good
interface for telling things like objcopy or strip which one is currently in
use.)
Any comments on the two options?
--
Daniel Jacobowitz
More information about the Binutils
mailing list