Re: Problem with arm-elf -> arm-a.out objcopy

[Jason R Thorpe <thorpej at wasabisystems dot com>]

On Thu, Nov 01, 2001 at 09:47:29AM -0500, Quality Quorum wrote:

 > IMHO, write a small utility which will fix aout headers the way you feel
 > appropriate.

Unfortunately, that's really a non-answer.

So, I tried coaxing objcopy to produce an NMAGIC executable -- in such
executables, the a.out header is not part of the .text segment, so
that 32 byte adjustment isn't necessary.

The problem, however (and I'm pretty sure this has been brought up
before), is that the BFD ELF backend simply refuses to create anything
NMAGIC-like.  I think the following snippet of code, from elf.c
assign_file_positions_for_segments(), is at fault:

          if ((abfd->flags & D_PAGED) != 0)
            off += (m->sections[0]->vma - off) % bed->maxpagesize;
          else
            {
              bfd_size_type align;

              align = 0;
              for (i = 0, secpp = m->sections; i < m->count; i++, secpp++)
                {
                  bfd_size_type secalign;

                  secalign = bfd_get_section_alignment (abfd, *secpp);
                  if (secalign > align)
                    align = secalign;
                }

              off += (m->sections[0]->vma - off) % (1 << align);
            }

Now, as far as I can tell, what's happening here is that:

	if demand-paged, align the file offset to the max page size.
	Otherwise, find the maximum program section alignment and
	align the file offset to that.

Please correct me if I'm wrong, but program section alignment is
e.g.:

Program Header:
    LOAD off    0x00008000 vaddr 0xf0000000 paddr 0xf0000000 align 2**15
         filesz 0x0015c188 memsz 0x0015c188 flags r-x
    LOAD off    0x00164188 vaddr 0xf0164188 paddr 0xf0164188 align 2**15
         filesz 0x00006b44 memsz 0x0002bde8 flags rw-
private flags = 2: [APCS-32] [has entry point]

...which fits with the file offset:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0015c188  f0000000  f0000000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

Now, is there any good reason for doing this in a non-D_PAGED
image?  I know "p_align" is "memory and file alignment", but
this effectively makes the image to be interpreted as demand
paged again, which causes the a.out back-end to write ZMAGIC.

Maybe the right question to ask is -- "Where does that 2**15
alignment come from?"  I'll note that "ld -N" seems to do
the right thing with the file offset:

netbsd:     file format elf32-littlearm
netbsd
architecture: arm, flags 0x00000012:
EXEC_P, HAS_SYMS
start address 0xf0000000

Program Header:
    LOAD off    0x00000080 vaddr 0xf0000000 paddr 0xf0000000 align 2**4
         filesz 0x00162ccc memsz 0x00187f70 flags rwx
private flags = 2: [APCS-32] [has entry point]

The difference between the .xn and .xbn linker scripts is:

--- armelf_nbsd.xn      Wed Oct 31 17:47:46 2001
+++ armelf_nbsd.xbn     Wed Oct 31 17:47:46 2001
@@ -151,7 +151,7 @@
   .sbss2   : { *(.sbss2) *(.sbss2.*) *(.gnu.linkonce.sb2.*) }
   /* Adjust the address for the data segment.  We want to adjust up to
      the same address within the page on the next page up.  */
-  . = ALIGN(0x8000) + (. & (0x8000 - 1));
+  . = .;
   .data    :
   {
     __data_start = . ;

I guess that's where the 2**15 is coming from.

This seems wrong -- it seems to me, rather, that phdr->p_align should come
from the largest shdr->sh_addralign that makes up the segment described by
phdr if the output BFD is not D_PAGED (which in the case of this executable
image would be 2**4).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>