[llvm-bugs] [Bug 45370] New: wrong/misleading "SHF_MERGE section size must be a multiple of sh_entsize"

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Mar 31 02:57:53 PDT 2020


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

            Bug ID: 45370
           Summary: wrong/misleading "SHF_MERGE section size must be a
                    multiple of sh_entsize"
           Product: lld
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: andrew at tao11.riddles.org.uk
                CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com

Corresponding FreeBSD bug linked as "see also"; see that bug's own "see also"
link for where this came from.

In ObjFile<ELFT>::shouldMerge in lld/ELF/InputFiles.cpp:

  if (sec.sh_size % entSize)
    fatal(toString(this) + ":(" + name + "): SHF_MERGE section size (" +
          Twine(sec.sh_size) + ") must be a multiple of sh_entsize (" +
          Twine(entSize) + ")");

  uint64_t flags = sec.sh_flags;
  if (!(flags & SHF_MERGE))
    return false;

Notice that the size is being checked _before_ the SHF_MERGE flag is checked.
This means that either the logic is incorrect, or the error message is
incorrect (since this error will then occur for sections without SHF_MERGE).

If this size check is only needed for mergeable sections, then surely it should
be made _after_ SHF_MERGE is checked for.

Since this check is skipped when -O0 is in effect, I do not believe it is
actually necessary to check that size is a multiple of sh_entsize when _not_
merging sections. If I'm wrong about that, though, then the check would need to
be both moved to somewhere else and changed to not mention SHF_MERGE in the
error message.

-- 
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/20200331/0e48d413/attachment-0001.html>


More information about the llvm-bugs mailing list