Re: GNU LD Bug

[Ian Lance Taylor]

   Andrew Mirsky <address@hidden> writes:

   Using the command file:
   SECTIONS
   {
        my_first_section 0x1000 : { *(.my_first_section) }
        my_second_section 0x2000 : { *(.my_second_section) }
   }
   
   OUTPUT_FORMAT("elf64-sparc")
   OUTPUT_ARCH(sparc:v9a)
   
   I was able to produce the following sections (from elfdump):
   Section Header[1]:  sh_name: my_second_section
       sh_addr:      0x2000          sh_flags:   0
       sh_size:      0x1e000         sh_type:    [ SHT_PROGBITS ]
       sh_offset:    0               sh_entsize: 0
       sh_link:      0               sh_info:    0
       sh_addralign: 0x10000       
   
   Section Header[2]:  sh_name: my_first_section
       sh_addr:      0x1000          sh_flags:   0
       sh_size:      0x3008          sh_type:    [ SHT_PROGBITS ]
       sh_offset:    0x1e000         sh_entsize: 0
       sh_link:      0               sh_info:    0
       sh_addralign: 0x2000
   
   The address of my_first_section plus its size is beyond the starting
   address of my_second_section. 
   
   It should warn/error me that I am overlapping sections in virtual
   address space? Or perhaps the problem is that I am trying to move around
   non-allocatable sections? Shouldn't this be a warning as well?

The linker should warn about overlapping sections if they are
allocatable (SHF_ALLOC).  But it doesn't warn about overlapping
sections which are not allocatable, and it shouldn't: DWARF debugging
sections all start at virtual address zero.

Setting the address of a non-allocatable section is a meaningful
operation, so the linker shouldn't warn about it.

In the general, the linker does not try to protect you against
yourself.  You are presumed to know what you are doing.

Ian