[llvm-bugs] [Bug 42006] New: LLD is not assigning an OutputSection of type OVERLAY an address.

[via llvm-bugs]

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

            Bug ID: 42006
           Summary: LLD is not assigning an OutputSection of type OVERLAY
                    an address.
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            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

When attempting to test Thunk reuse between two OVERLAY OutputSections which we
shouldn't do as only one will be in memory at a time I came across a relocation
out of range error as Thunks were not created at all. On further inspection the
LMA and VMA expressions were all ignored with 0 being the result.

I think that this is due to the requirement of OVERLAY to clear the SHF_ALLOC
flag on the OutputSection. This seems to prevent Thunk Creation and causes the
LMA and VMA to be ignored.

cat overlay.s
         .section .sec1, "ax", %progbits
          bl far

          .section .sec2, "ax", %progbits
          bl far

          .section .sec3, "ax", %progbits
          .globl far
          .type far, %function
far:    bx lr

cat overlay.lds
SECTIONS {
    .sec1 0x1000 (OVERLAY) : AT (0x1000) { *(.sec1) }
    .sec2 0x1000 (OVERLAY) : AT (0x2000) { *(.sec2) }
    .far  0x10000000 : { *(.sec3) }
  }

llvm-mc --triple=armv7-a-linux-gnueabihf overlay.s -filetype=obj -o overlay.o
ld.lld overlay.o --script overlay.lds
ld.lld: error: overlay.o:(.sec1+0x0): relocation R_ARM_CALL out of range:
268435448 is not in [-33554432, 33554431]
ld.lld: error: overlay.o:(.sec2+0x0): relocation R_ARM_CALL out of range:
268435448 is not in [-33554432, 33554431]

cat overlay2.lds
SECTIONS {
    .sec1 0x1000 (OVERLAY) : AT (0x1000) { *(.sec1) }
    .sec2 0x1000 (OVERLAY) : AT (0x2000) { *(.sec2) }
    .far  0x3000 : { *(.sec3) }
  }
ld.lld overlay.o --script overlay2.lds -o overlay --print-map
     VMA      LMA     Size Align Out     In      Symbol
       0        0        4     1 .sec1
       0        0        4     1         overlay.o:(.sec1)
       0        0        0     1                 $a.0
       0        0        4     1 .sec2
       0        0        4     1         overlay.o:(.sec2)
       0        0        0     1                 $a.1
       0        0       7a     1 .comment
       0        0       7a     1         <internal>:(.comment)
       0        0       50     4 .symtab
       0        0       50     4         <internal>:(.symtab)
       0        0       3b     1 .shstrtab
       0        0       3b     1         <internal>:(.shstrtab)
       0        0       14     1 .strtab
       0        0       14     1         <internal>:(.strtab)
    3000     3000        4     1 .far
    3000     3000        4     1         overlay.o:(.sec3)
    3000     3000        0     1                 $a.2
    3000     3000        0     1                 far
    3004     3004        0     4 .text
    3004     3004        0     4         overlay.o:(.text)

This is in contrast with arm-linux-gnueabihf-ld.bfd
LOAD overlay.o

.sec1           0x0000000000001000       0x10
 *(.sec1)
 .sec1          0x0000000000001000        0x4 overlay.o
 *fill*         0x0000000000001004        0x4 
 .sec1.__stub   0x0000000000001008        0x8 linker stubs

.sec2           0x0000000000001000       0x10 load address 0x0000000000002000
 *(.sec2)
 .sec2          0x0000000000001000        0x4 overlay.o
 *fill*         0x0000000000001004        0x4 
 .sec2.__stub   0x0000000000001008        0x8 linker stubs

.far            0x0000000010000000        0x4 load address 0x0000000010001000
 *(.sec3)
 .sec3          0x0000000010000000        0x4 overlay.o
                0x0000000010000000                far


Note that ld.bfd has removed the SHF_ALLOC after assigning addresses and has
created stubs (thunks) in each overlay as we would expect.

In summary I think:
-LLD should not hard-code the address of a non-alloc section to 0.
-LLD should permit thunks to be generated from OVERLAY regions.
-LLD should prohibit thunks from being shared with an OVERLAY region.

-- 
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/20190524/a3674126/attachment.html>