BUG: Not enough room for program headers, try linking with -N

[Tobias Ringstrom]

When I found the new binutils release 2.13 today, I remembered my bug
reports from April.  The first one was fixed thanks to Nick, but the
second one is still a problem.  I've included the second problem here,
slightly edited and expanded:

On 10 Apr 2002, Nick Clifton wrote:

> On Wed, 10 Apr 2002, Tobias Ringstrom wrote:
> 
> > I also think there is something strange going on with the automatic
> > ELF PHDRS generation, at least for ARM.  I'll look closer at that
> > soon, but I wondering if this is a known trouble area.
> 
> It can be a problem if you are using a custom linker script, or you
> are run strip on your linked executable.  But the code should be doing
> the right thing, so if something is going wrong, then it is a bug.

Yes, it is a custom link script, but that is supported, isn't it?  I've
tried to make it really really short.  First, here is my source code,
crt.s:

        .text
        .balign         4
        .global         __reset
__reset:
        nop
        nop
        nop
        nop
        nop
        nop
        nop
        nop

And here is my link script, tmp2.lds:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(__reset)
SECTIONS
{
        .text 0 : AT ( 0x2000 ) { *(.text); }
}

Then I run the following:
$ arm-elf-as crt.s -o crt.o
$ arm-elf-ld -Ttmp2.lds crt.o
arm-elf-ld: a.out: Not enough room for program headers, try linking with -N
arm-elf-ld: final link failed: Bad value

Why does it tell me to use -N?  Wouldn't -n be a better choice (now that
it works)?

If I change the vaddr of the .text section from 0 to say 0x1000, it works,
but then the program headers look strange (the first one is completely 
strange, and the alignment is weird):

------------------------------------------------------------------------
$ arm-elf-objdump -hp a.out

a.out:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00001020 memsz 0x00001020 flags rwx
    LOAD off    0x00009000 vaddr 0x00001000 paddr 0x00002000 align 2**15
         filesz 0x00000020 memsz 0x00000020 flags r-x
private flags = 0: [APCS-32] [FPA float format]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000020  00001000  00002000  00009000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .glue_7       00000000  00001020  00001020  00001020  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .glue_7t      00000000  00001020  00001020  00001020  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         00000000  00001020  00001020  00001020  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000000  00001020  00001020  00001020  2**0
                  ALLOC
------------------------------------------------------------------------

(It does not help to add "support" for .data and .bss)

Do you agree that I should not need --nmagic in this case, or is there 
something wrong with my link script?

If I link using the -n option, it works as expected, and I get the
following correct output:

------------------------------------------------------------------------
$ arm-elf-ld -Ttmp2.lds -n crt.o
$ arm-elf-objdump -hp a.out

a.out:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000074 vaddr 0x00001020 paddr 0x00001020 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rwx
    LOAD off    0x00000074 vaddr 0x00001000 paddr 0x00002000 align 2**2
         filesz 0x00000020 memsz 0x00000020 flags r-x
private flags = 0: [APCS-32] [FPA float format]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000020  00001000  00002000  00000074  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .glue_7       00000000  00001020  00001020  00000074  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .glue_7t      00000000  00001020  00001020  00000074  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         00000000  00001020  00001020  00000074  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  4 .bss          00000000  00001020  00001020  00000074  2**0
                  ALLOC
------------------------------------------------------------------------

Although this is correct, the first program header is superfluous.  It
does not matter much, but it looks a bit ugly.  It might be related to the
main problem.

/Tobias