[llvm-bugs] [Bug 33714] New: Size sanity check is pessimistic

[via llvm-bugs]

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

            Bug ID: 33714
           Summary: Size sanity check is pessimistic
           Product: lld
           Version: unspecified
          Hardware: Other
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: eblot.ml at gmail.com
                CC: llvm-bugs at lists.llvm.org

I'm trying to link a Cortex-M4 (ARMv7EM) ELF bare metal binary, with LLD 5.0
(from the trunk). All input object files have been generated with clang/llvm.

The linker script defines 397312 bytes for code/rodata storage in flash region.

GNU LD (2.28) linker links without any issue, there is a large portion of
storage that is left empty.

However LLD refuses to link, as it detects overflows in the destination region.

Increasing the available storage space enables to link successfully, and the
resulting ELF binary seems to be valid, while the size of each section seems to
be match the expected values (closes to the ones obtained with GNU LD):

$ armv7em-none-eabi-readelf -S output.elf
There are 23 section headers, starting at offset 0x95198:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf
Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0 
0
  [ 1] .isr_vector       PROGBITS        0001f000 0000b4 000200 00      0   0 
4
  [ 2] .debug_str        PROGBITS        00000000 0002b4 020162 01  MS  0   0 
1
  [ 3] .debug_loc        PROGBITS        00000000 020416 000f4c 00      0   0 
1
  [ 4] .debug_abbrev     PROGBITS        00000000 021362 004cae 00      0   0 
1
  [ 5] .debug_info       PROGBITS        00000000 026010 025e36 00      0   0 
1
  [ 6] .debug_ranges     PROGBITS        00000000 04be46 001890 00      0   0 
1
  [ 7] .debug_macinfo    PROGBITS        00000000 04d6d6 00003a 00      0   0 
1
  [ 8] .debug_pubnames   PROGBITS        00000000 04d710 0057e3 00      0   0 
1
  [ 9] .debug_pubtypes   PROGBITS        00000000 052ef3 0092b4 00      0   0 
1
  [10] .comment          PROGBITS        00000000 05c1a7 001184 01  MS  0   0 
1
  [11] .ARM.attributes   ARM_ATTRIBUTES  00000000 05d32b 000049 00      0   0 
1
  [12] .debug_frame      PROGBITS        00000000 05d374 004c4c 00      0   0 
4
  [13] .debug_line       PROGBITS        00000000 061fc0 014b59 00      0   0 
1
  [14] .debug_aranges    PROGBITS        00000000 076b19 000100 00      0   0 
1
  [15] .symtab           SYMTAB          00000000 076c1c 007b20 10     17 1748 
4
  [16] .shstrtab         STRTAB          00000000 07e73c 0000f9 00      0   0 
1
  [17] .strtab           STRTAB          00000000 07e835 003754 00      0   0 
1
  [18] .text             PROGBITS        0001f200 081fc0 00ed03 04 AXMS  0   0
64
  [19] .data             PROGBITS        20002000 090cc4 0004d0 00  WA  0   0 
4
  [20] .bss              NOBITS          20003cb8 091194 000c08 00  WA  0   0 
4
  [21] .heap             PROGBITS        20025448 091198 002000 00      0   0 
8
  [22] .stack_dummy      PROGBITS        20027448 093198 002000 00      0   0 
8
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)

Replacing the error message in LinkerScript::output with a simple info message
and reverting back to the original storage definitions also generates a valid
ELF file - from a section size perspective at least.

The computed overflow values seem quite large compared to the actually
generated sections:

  "section '.text' will not fit in region 'FLASH': overflowed by 17032371
bytes"

whereas the resulting .text section is actually 60675 byte long.

I do not known the LLD intrinsics but it seems the size computation fails for
some reason with this configuration.

-- 
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/20170707/7b5bae0d/attachment-0001.html>