[llvm-bugs] [Bug 41357] New: LLD . assignment outside of SECTIONS can overflow MEMORY Region spuriously

[via llvm-bugs]

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

            Bug ID: 41357
           Summary: LLD . assignment outside of SECTIONS can overflow
                    MEMORY Region spuriously
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: peter.smith at linaro.org
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

Consider the following example:
cat memregions.lds
MEMORY {
    FLASH (rx) : ORIGIN = (0x0 + 0x0), LENGTH = (256*1K - 0x0)
    SRAM (wx) : ORIGIN = 0x20000000, LENGTH = (64 * 1K)
}


SECTIONS {
 .text : { *(.text) } > FLASH
 . = 0x20000000;
 .data : { *(.data) } > SRAM AT> FLASH
}

cat memregion.s
.text 
 nop

.data
.word 0

ld.lld memregion.o -T memregion.lds
ld.lld: error: section '.text' will not fit in region 'FLASH': overflowed by
536608768 bytes
ld.lld: error: section '.data' will not fit in region 'FLASH': overflowed by
536608768 bytes
ld.lld: error: section '.data' will not fit in region 'FLASH': overflowed by
536608770 bytes

I tracked this down to LinkerScript::setDot(), in particular:
  // Update to location counter means update to section size.
  if (InSec)
    expandOutputSection(Val - Dot);
  else
    expandMemoryRegions(Val - Dot);

The . = 0x20000000; in the linker script which is supposed to set dot for the
next memory region is adding 512 Megabytes to the size of the .text
OutputSection. This does not happen with ld.bfd.

 I believe this part of the code was added for
https://bugs.llvm.org//show_bug.cgi?id=37836 which had a linker script with
something like:

    MEMORY
    {
      ram (wxa) : ORIGIN = 0x42000, LENGTH = 0x100000
    }

    SECTIONS
    {
      .text :
      {
        *(.text*)
      }

      aligned_dot = ALIGN(0x10 * 1024);  

      .data aligned_dot :
      {
        *(.data*)
      }
    }

I would certainly not expect assigning to . to add anything to a memory region,
what I would expect is that the effect of assigning to . would affect the start
address of the next OutputSection and that would trigger a corresponding change
in the Memory Region. So I think we may need to add/alter the fix for pr37836.

The linker script was cut down from the Zephyr RTOS Linker Script so this is a
use case from a real program.

-- 
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/20190403/0ea358fb/attachment.html>