This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ARM section alignment
On Thu, 2008-06-12 at 13:09 +0100, Nick Clifton wrote:
> The alignment of the program headers is set to the page size value for
> the target, so that they will start on a page boundary. Look at the
> definition of ELF_MINPAGESIZE in bfd/elf32-arm.c. If it makes sense for
> this to be a smaller value for your target then feel free to change it
> (in a similar way to how ELF_MAXPAGESIZE is set for the QNX targets).
Conceptually that makes sense, but the behavior I am seeing doesn't
quite correspond to what you say. In elf32-arm.c, ELF_MINPAGESIZE is
0x1000, which would induce an alignment of 2**12. Is it possible that
the alignment is actually being dictated by ELF_MAXPAGESIZE (0x8000 for
non-QNX targets)?
Three follow-up questions:
1. Just so I can review the relevant logic to ensure that I understand
how this all works, can you point me at the code which is setting
up the program header alignment?
2. Is there a way to override this in a configuration file (perhaps
a header file) rather than patching elf32-arm.c?
If not, *should* there be?
3. Is it the case that the MINPAGESIZE/MAXPAGESIZE settings in the
ld emultempl files must match the ones in libbfd, or are these
independent considerations?
While we are on this, I confess that the choice of 0x8000 for
ELF_MAXPAGESIZE seems very strange. The ARM MMU hardware does not
implement 32k pages. The valid choices are 1k, 4k, and 64k. I would
therefore expect naively that the values here would have ELF_MINPAGESIZE
of 0x400 (1K) and ELF_MAXPAGESIZE of 0x10000 (64k). Neither is true.
The only use-case I can see for ELF_MAXPAGESIZE=32k is that this
alignment matches the alignment requirements for the translation table
base register. I certainly see why that is important, but it seems like
something that should more properly be accomplished in a kernel ldscript
than in the BFD built-in assumptions.
Do you happen to know why the current choice is what it is?
Thanks again for your help on this, Nick.
shap