[llvm-bugs] [Bug 36771] New: warning: found local symbol in global part of symbol table with Swift compiled code

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Mar 16 11:33:32 PDT 2018


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

            Bug ID: 36771
           Summary: warning: found local symbol in global part of symbol
                    table with Swift compiled code
           Product: new-bugs
           Version: trunk
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: alblue at apple.com
                CC: llvm-bugs at lists.llvm.org

When compiling Swift on Linux with 4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a and
LLD 6.0, I see a warning generated at link time complaining that a found local
symbol in global part of symbol table:

/tmp/cross-toolchain/swift.xctoolchain/usr/bin/ld.lld: warning: found local
symbol '__stop_swift2_protocol_conformances' in global part of symbol table in
file
/private/tmp/cross-toolchain/swift.xctoolchain/usr/lib/swift/linux/libFoundation.so
/tmp/cross-toolchain/swift.xctoolchain/usr/bin/ld.lld: warning: found local
symbol '__start_swift3_typeref' in global part of symbol table in file
/private/tmp/cross-toolchain/swift.xctoolchain/usr/lib/swift/linux/libFoundation.so
/tmp/cross-toolchain/swift.xctoolchain/usr/bin/ld.lld: warning: found local
symbol '__start_swift3_reflstr' in global part of symbol table in file
/private/tmp/cross-toolchain/swift.xctoolchain/usr/lib/swift/linux/libFoundation.so

This apparently is a new feature added in LLD 6.0 (see
https://reviews.llvm.org/D41257). The question is, why is Swift (which uses
LLVM as the back end) writing local symbols in a global symbol table if this is
not allowed as per the ELF spec?

According to the author of the warning:

"
Look at Figure 1-13 on this PDF page 19 of
http://www.skyfree.org/linux/references/ELF_Format.pdf to see what it is. It
says that sh_info member in a section header for the symbol type (of type
SHT_SYMTAB and SHT_DYNSYM) must have an index one greater than the symbol table
index of the last local symbol (binding STB_LOCAL).
So, in a symbol table, all symbols after sh_info index must be non-local. That
warning message is emitted when lld found a violation of the spec.
If you want to fix it, you probably need to sort a symbol table so that all
local symbols are at beginning of a table, and set its last index + 1 to
sh_info member of the symbol table section header.
"

The question is why isn't LLVM's ELF backend performing this step, and
generating a potentially invalid ELF file?

For cross-reference purposes, the bug at Swift.org is
https://bugs.swift.org/browse/SR-7189 and the corresponding location where the
Swift compiler emits the symbols is
https://github.com/apple/swift/blob/master/stdlib/public/runtime/SwiftRT-ELF.cpp#L21-L37
- the symbols are marked with an independent section and hidden visibility
symbols:

 __asm__("\t.section " #name ",\"a\"\n");                                     \
  __attribute__((__visibility__("hidden"))) extern const char __start_##name; 
\
  __attribute__((__visibility__("hidden"))) extern const char __stop_##name;

FWIW when LLD 5 was being used to link the project, these same symbols weren't
being added to the dynamic exports automatically (which they were when linked
with Gold). I suspect the same issue exists for both.

The generated so that was causing the complaints is downloadable from the
libFoundation.so in the Swift download, which for the above is at
https://swift.org/builds/swift-4.1-branch/ubuntu1604/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-ubuntu16.04.tar.gz
and the file at
swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-ubuntu16.04/usr/lib/swift/linux/libFoundation.so

-- 
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/20180316/e577c755/attachment-0001.html>


More information about the llvm-bugs mailing list