Bad behavior with explicit phdrs and loadable orphans

[David Heine <dlheine at tensilica dot com>]

When explicit PHDRs and memory regions are used with orphan input 
sections, the default placement of these sections can generate either 
very large files or a SEEK overflow.

Here is a small example of a seek overflow for an x86 target.  I would 
send an example of the large file generation, but it doesn't seem very 
neighborly.

> cat small-x86.s
        .section .foo, "ax"
        # nothing here.  Builds a allocatable section of 0 size
        .align 4
        .section .text
fn:
        pushl   %ebp
        movl    %esp, %ebp
        movl    $0, %eax
        popl    %ebp
        ret

> cat link-x86.t
MEMORY
{
  normal_seg : ORIGIN = 0xd0000000, LENGTH = 0x10000
}

PHDRS
{
  normal_phdr PT_LOAD;
}

SECTIONS
{

  .text :
  {
    *(.text)
  } >normal_seg :normal_phdr

  .data :
  {
    *(.data)
  } >normal_seg :normal_phdr

  .bss :
  {
    *(.bss)
  } >normal_seg :normal_phdr

}

> gcc -c small-x86.s
> ld -Tlink-x86.t -o small-x86.exe small-x86.o
ld: warning: no memory region specified for section `.foo'
ld: final link failed: File truncated

This actual rather cryptic error is caused by a call to fseek with a 
negative argument.  The default placement of the ".foo" section is in 
the "*default*" memory at address 0, the PHDR where it is placed has 
memory that starts at 0xd0000000.  The system fails to build an output 
file large enough to map addresses from 0x0 to 0xd0000000.

If the start address of the "normal_seg" is set to 0x40000000, no 
overflow will occur, but the linker will build a VERY large file (and 
crash some machines with less robust filesystems).

This behavior seems a little extreme for misnaming a loadable section, 
but I'm not sure what a good solution would be.  The ld orphan placement 
algorithm seems to be looking for a good place to put the section in the 
emulation statements.  Perhaps it just needs to look for a good memory 
region while placing an orphan as well.  Alternatively, when explicit 
PHDRS are used, the linker could do a better job of placing the default 
memory section so that it was reasonably contiguous with an existing 
PHDR.   Or perhaps orphan loadable sections should generate an error 
when using explicit PHDRs before the attempt is made to build a 
multi-gigabyte file.

Any thoughts on a solution to this problem?

-David