New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-7189] warning: found local symbol in global part of symbol table #49737
Comments
@compnerd Can we get rid of those ___start/___stop symbols now? |
Oh, I was confused here. These are the new symbols that replace the old begin/end sections. They're defined by the DECLARE_SWIFT_SECTION macro in stdlib/public/runtime/SwiftRT-ELF.cpp. @compnerd suggested to me that this might be a bug in lld. Alex, do you get the same warnings when using gold? |
I don't see the same warnings emitted with either gold: $ ./ld.gold --version or with LLD 5: $ ./ld.lld --version The warnings are only seen with LLD 6: $ ./ld.lld --version |
That is consistent with @compnerd's hypothesis that this is a bug in lld. |
It looks like it is a new feature introduced into lld explicitly: https://llvm.googlesource.com/lld/+/2f69df6d20fdf8e49fd3685e69b51df7406ac918%5E%21/#F1 Use warn() instead of error() to report a bad symbol in a DSO.
Specifically, libwidevinecdm.so in Chrome has such bad symbol.
It seems the BFD linker handles them as local symbols, so instead
of inserting them to the symbol table, we should skip them too.
Differential Revision: https://reviews.llvm.org/D41257 The question is, is the warning correct? |
So I reached out to the author of the change above, and received a response:
|
In that case, it seems like an LLVM problem. |
One other thing (which may be worth noting here) - when linking an app with Gold on Swift 4.0.3, the older variants of the start/stop symbols were present in the dynamic symbol table but not when linked with lld 5.0. To get LLD working with Swift 4.0.3, I had to add --export-dynamic. Otherwise the following symbols weren't copied over: .swift2_type_metadata I suspect the same issue is present for this issue as well, where the symbols are appearing local but sorted in place with the global symbols to mark start/end sections. If the strict reading of the spec is correct, it's not possible to have local symbols intermingled with the global ones. |
Raised cross-reference bug at LLVM: |
So for the record, it seems to be that the creation of the libFoundation.so (using these start/stop symbols) causes problems. Readelf (from binutils 2.28+) has a warning message, added last year, to warn when local symbols show up in the .dysm: Running readelf --symbols on libFoundation.so seems to suggest it is the only problematic library; others in the Swift runtime don't appear to be affected. It's not clear if there are other aspects that the compiler will generate that will cause those symbols to be emitted. {{ The issue is that these symbols are being emitted as LOCAL in the .dynsym section, which is presumably not the intent. |
Also, I should point out that these stray symbols aren't part of Swift 4.0.3 libFoundation.so, so the way that Foundation is built between then and now has caused this issue. |
We didn't use those symbols at all in Swift 4.0.3. I can't see how they would end up being present in libFoundation.so's .dynsym section. That seems like a bug on the Swift side. @compnerd, any ideas? |
Sorry @bob-wilson I should have been clearer ... when I tested against 4.0.3, I didn't see any symbols reported as warnings from either readElf or LLD. I wanted to highlight that this is a new issue for the 4.1-branch, as opposed to the specific symbols in the original bug report. |
@compnerd can you comment on this? |
The start/stop symbols should be created by the linker. We have declarations for them in the object. However, we explicitly adjust the visibility to mark them hidden as we do not want the symbols exported. The section symbol doesn't need to be exported at all (e.g. {{.swift4_reflstr}}). The addition of the attributes should actually prevent the start/stop symbols associated with the section from being exported. |
@compnerd can you investigate why they are in fact being exported in the build of libFoundation.so, and find a way to fix it? |
I can try to take a look at that. I suspect that it may be the result of using a different linker (BFD) rather than gold or lld. |
Yes, it looks like the build on Ubuntu will pick up gold as the linker for the rest of the build, but CoreFoundation's build.py script doesn't get the option passed through. |
I ran a test building Foundation on Ubuntu 14.04. When 'ld' points to 'ld.bfd' we see the errors reported above. When 'ld' points to 'ld.gold' then the library is built correctly. So if we're using ld.gold for the Swift build (and passing -fuse-ld=gold) then we should ensure this is propagated through to the Foundation build, which will fix this issue. |
So the solution appears to be to add --linker=gold to the invocation of the Foundation configure script. Once this is done, the linker used to create libFoundation is the same as is used to create the rest of the Swift library stack, and the problems are fixed. |
This has been fixed with apple/swift-corelibs-foundation@6c54c84 on master, but needs to be backported - leaving this open until that has been done. |
This has now been back ported to release branches: Swift 4.1: apple/swift-corelibs-foundation#1535 Swift 4.2: apple/swift-corelibs-foundation#1533 |
Additional Detail from JIRA
md5: ca62783111acf441a6cf410146381371
Issue Description:
When using the cross-compilation script in swift package manager, and using lld 6.0 for the linking, a number of warnings are printed regarding local symbols:
This can be reproduced as follows:
1. Download the build_ubuntu_cross_compilation_toolchain from the pull request here:
https://raw.githubusercontent.com/alblue/swift-package-manager/fdcdde0582dfad3f10f8e8dc6f149cac8c1b328e/Utilities/build_ubuntu_cross_compilation_toolchain
2. Run this with:
VERSION=4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a ./build_ubuntu_cross_compilation_toolchain
3. Copy the instructions to download the appropriate ubuntu and macOS images, and then run with:
Download the Swift binaries for Ubuntu and macOS
curl -o ~/Downloads/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-ubuntu16.04.tar.gz 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
curl -o ~/Downloads/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-osx.pkg https://swift.org/builds/swift-4.1-branch/xcode/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-osx.pkg
Compile the SDK and toolchain from that
./build_ubuntu_cross_compilation_toolchain /tmp/ ~/Downloads/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-osx.pkg ~/Downloads/swift-4.1-DEVELOPMENT-SNAPSHOT-2018-03-11-a-ubuntu16.04.tar.gz
Create a test application
mkdir my-test-app
cd my-test-app
swift package init --type=executable
4. Modify the my-test-app/Sources/my-test-app/main.swift file to
import Foundation
print("Hello, world!")
5. Build it for Ubuntu
swift build --destination /tmp/cross-toolchain/ubuntu-xenial-destination.json
This should give the warning messages above.
To test whether this is fixed, substituting the version numbers in the downloads will result in a newly built toolchain that should work.
The text was updated successfully, but these errors were encountered: