Link error with today's CVS binutils

[Eric DeVolder <devolder at evsx dot com>]

I've built GCC 2.95.2 with today's CVS head for a ppc-elf as the target.
The software is a simple, fixed-address app that gets downloaded into
RAM of an eval board and then run. When linking, I get what I believe is
an error with the placement of the sections as directed by this linker
script:

OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
OUTPUT_ARCH(powerpc)
ENTRY(main)
MEMORY
{
    ram1    : org = 0x00010000, len = 0x00030000 /* 256K data */
    ram2    : org = 0x00040000, len = 0x00040000 /* 256K code */
}

SECTIONS
{
    .text   :
    {
        *(.text)
        *(.rodata)
        /* ALIGN ???? */
        PROVIDE (__DATA_ROM = .);
    } > ram2

    .klog (NOLOAD) :
    {
        PROVIDE (__KLOG_START = .);
        . = . + 0x00000400;
        PROVIDE (__KLOG_END = .);
    } > ram1

    .data   :
    {
        PROVIDE (__DATA_RAM = .);
        PROVIDE (__DATA_ROM = .);
        PROVIDE (__DATA_START = .);
        *(.data)
        *(.got)                     /* to make the linker happy */
        PROVIDE (__DATA_END = .);
    } > ram1

    .bss (NOLOAD)   :
    {
        PROVIDE(__BSS_START = .);
        *(.bss)
        *(COMMON)
        PROVIDE(__BSS_END = .);
        . = . + 16;
        PROVIDE(__HEAP_START = .);
        . = . + 0x00020000;
        PROVIDE(__HEAP_END = .);
        PROVIDE(__SP_END = .);
        . = . + 0x00002000;
        PROVIDE(__SP_INIT = .);
        PROVIDE(__ISP_BOT = .);
        . = . + 0x00002000;
        PROVIDE(__ISP_TOP = .);
    } > ram1

    /*
     * The .sdata and .sdata2 sections are provided below solely
     * for the purpose of making the GNU linker happy. They should
     * NOT contain any items whatsoever. You should verify this.
     */
    .sdata (NOLOAD)     :
    {
        *(.sdata)
        *(.sbss)
    } > ram1

    .sdata2 (NOLOAD)    :
    {
        *(.sdata2)
        *(.sbss2)
    } > ram1

    /DISCARD/ :
    {
        *(*)
    }
}

The important thing to note here is that the .klog section is of length
0x0400 and is placed into ram1, (0x00010000 to 0x000103FF). The .data
section is placed after .klog into ram1, and should start at 0x00010400.

Instead, after linking with todays CVS binutils, .klog and .data are
both placed at the beginning of ram1 (ie overlap), which causes the app
to fail.

obj/gnu/dos/a.out:     file format elf32-powerpc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00023180  00040000  00040000  00020000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .klog        00000400  00010000  00010000  00043180  2**0
                  CONTENTS
  2 .data         00000038  00010000  00010000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0002473c  00010038  00010038  00010038  2**2
                  ALLOC
  4 .sdata        00000000  00034774  00034774  00010038  2**2
                  ALLOC
  5 .sdata2       00000000  00034774  00034774  00010038  2**2
                  ALLOC, READONLY

Here is the same application, but built using Binutils 2.9.1, which
correctly places the .data section after the .klog section into ram1.

obj/gnu/dos/a.out:     file format elf32-powerpc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00023180  00040000  00040000  00010000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .klog        00000400  00010000  00010000  00033180  2**0
                  CONTENTS
  2 .data         00000048  00010400  00010400  00000400  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0002473c  00010448  00010448  00000448  2**2
                  ALLOC
  4 .sdata        00000000  00034b84  00034b84  00000448  2**2
                  ALLOC
  5 .sdata2       00000000  00034b84  00034b84  00000448  2**2
                   ALLOC, READONLY

Note that the .bss is correctly placed after the .data in ram1, so this
is OK.

Is this an issue with an arbitrary output section (for elf), or
something else?

Any ideas?

Eric