ARM section alignment

[Nick Clifton]

Hi Jonathan,

> 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)?

Yup - that was my mistake.

>  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?

See bfd/elf.c:assign_file_positions_for_load_sections() and look at the 
uses of the variable maxpagesize.

>  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?

-z max-page-size should work.

>  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?

They are independent but related.  (Note - Only MAXPAGESIZE is used in 
the linker scripts and emulation code).

The MAXPAGESIZE variable is used inside the default linker script to set 
the alignment of various segments. See the definition of 
DATA_SEGMENT_ALIGN in ld/scripttempl/elf.sc for an example.  There is 
however some undocumented magic in that if the definition of MAXPAGESIZE 
is not a number but rather the expression "CONSTANT (MAXPAGESIZE)" then 
it is automatically given the value of the maxpagesize variable defined 
for the current target in libbfd.

Cheers
   Nick



> 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
>