[llvm-bugs] [Bug 38626] New: INFO output type should make the section non-allocatable but it's allocated anyway

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38626

            Bug ID: 38626
           Summary: INFO output type should make the section
                    non-allocatable but it's allocated anyway
           Product: lld
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: djc at djc.id.au
                CC: llvm-bugs at lists.llvm.org

According to:

https://sourceware.org/binutils/docs/ld/Output-Section-Type.html#Output-Section-Type

for the DSECT, COPY, INFO, and OVERLAY output types "the section should be
marked as not allocatable, so that no memory is allocated for the section when
the program is run."

Lld understands those output types and it does... something with them. But the
section is still allocated in the final binary and the program header has an
empty load covering the section for no reason.

Here is an example for an embedded target. The .stack section is for
informational purposes only, it doesn't contain anything and needn't be
allocated at runtime.

$ cat test.c
int somedata = 123;
int somebss;
void _start(void) {
}
$ gcc -nostdlib -nostartfiles -c test.c
$ cat link.x 
MEMORY
{
  FLASH : ORIGIN = 0x20400000, LENGTH = 512M
  RAM : ORIGIN = 0x80000000, LENGTH = 16K
}
SECTIONS
{
  .text :
  {
    *(.text);
  } > FLASH

  .rodata :
  {
    *(.rodata);
  } > FLASH

  .bss :
  {
    *(.bss);
  } > RAM

  .data : AT(LOADADDR(.rodata) + SIZEOF(.rodata))
  {
    *(.data);
    . = ALIGN(4);
  } > RAM

  PROVIDE(_stack_start = ORIGIN(RAM) + LENGTH(RAM));
  .stack (INFO) :
  {
    _estack = .;
    . = _stack_start;
    _sstack = .;
  } > RAM

  /DISCARD/ :
  {
    *(.eh_frame);
  }
}
$ lld -flavor gnu -Tlink.x -o test test.o

If you use llvm-objdump -all-headers on the resulting binary you can see the
program header has a load of size 0x3ffc for the .stack section which should
not be there:

Program Header:
    LOAD off    0x0000000000001000 vaddr 0x0000000020400000 paddr
0x0000000020400000 align 2**12
         filesz 0x0000000000000007 memsz 0x0000000000000007 flags r-x
    LOAD off    0x0000000000002000 vaddr 0x0000000080000000 paddr
0x0000000080000000 align 2**12
         filesz 0x0000000000000000 memsz 0x0000000000000004 flags rw-
    LOAD off    0x0000000000002004 vaddr 0x0000000080000004 paddr
0x0000000000000000 align 2**12
         filesz 0x0000000000000004 memsz 0x0000000000003ffc flags rw-
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**64
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-

Compare when the program is linked with GNU ld:

$ ld -Tlink.x -o test.ld test.o

Program Header:
    LOAD off    0x0000000000200000 vaddr 0x0000000020400000 paddr
0x0000000020400000 align 2**21
         filesz 0x0000000000000007 memsz 0x0000000000000007 flags r-x
    LOAD off    0x0000000000400004 vaddr 0x0000000080000004 paddr
0x0000000020400007 align 2**21
         filesz 0x0000000000000004 memsz 0x0000000000000004 flags rw-
    LOAD off    0x0000000000600000 vaddr 0x0000000080000000 paddr
0x0000000080000000 align 2**21
         filesz 0x0000000000000000 memsz 0x0000000000000004 flags rw-
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**4
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180818/488da721/attachment.html>