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
Beginning support for ARMv7 hosts (RasPi, etc.) #439
Conversation
set(SWIFT_PRIMARY_VARIANT_SDK_default "LINUX") | ||
set(SWIFT_PRIMARY_VARIANT_ARCH_default "x86_64") | ||
|
||
if("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please leave a comment here that this only works for building a host compiler, and won't work for building cross-compilers.
There are soft float and hard float variants of armv7 ABI (and even multiple variants of those, IIRC). To ensure that the arm port is future-proof, the architecture name here needs to be something like |
@@ -1115,8 +1115,13 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job, | |||
// Add the linker script that coalesces protocol conformance sections. | |||
Arguments.push_back("-Xlinker"); | |||
Arguments.push_back("-T"); | |||
Arguments.push_back( | |||
context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld")); | |||
#if defined(__arm__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Swift is a cross-compiler, we don't do #if
s in the C++ sources. Please query the target and use the correct path. getTriple().getArchName()
, I think, but it should also include the gnueabihf
suffix, so please leave a fixme for that.
In general this looks good to me, please fix those issues and I'll merge. |
With this comment: "There are soft float and hard float variants of armv7 ABI (and even multiple variants of those, IIRC). To ensure that the arm port is future-proof, the architecture name here needs to be something like armv7-gnueabihf to allow other variants. This is not necessarily something you need to worry about right now, but could you file an issue about taking care of that in future, when the port is in a better shape?" It's not clear with block of code you're referring to. You're absolutely correct that I have made no attempt to correctly handle soft-float versions, or any other abis, for that matter. I'd like to learn more about how the target triples are passed through the build scripts so that these are correctly handled, as well as eventual hope for cross-compiling. I've implemented all of your suggestions (thank you for them!), and I'll let you know when I finish testing it all again. |
I'm referring to the code in general, where it uses
Currently we don't have anything like hard/soft variants for any of the supported architectures, so there isn't anything you can look at. The first approximation would be to just use |
// FIXME: This should also query the abi type (i.e. gnueabihf) | ||
if (getTriple().getArch() == llvm::Triple::arm) { | ||
Arguments.push_back( | ||
context.Args.MakeArgString(Twine(RuntimeLibPath) + "/armv7/swift.ld")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just concatenate in getTriple().getArchName()
? Or does it return something strange? If that's the case, convert the if
chain to switch.
The patch LGTM with those few issues fixed. May I also ask you to squash the commits? |
configure_sdk_unix(LINUX "Linux" "linux" "linux" "x86_64" "x86_64-unknown-linux-gnu") | ||
set(SWIFT_HOST_VARIANT_ARCH "x86_64") | ||
set(SWIFT_PRIMARY_VARIANT_ARCH_default "x86_64") | ||
else() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you make an explicit branch based on the CMAKE_SYSTEM_PROCESSOR
value? This will simplify adding further ports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that I've done this, but it's not clear from the pull request (apple:master hpux735:master) that it has been completed. Let me know if I need to try again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for being unclear, I meant instead of else()
assuming armv7
using an explicit value here.
Thank you, merging! |
Beginning support for ARMv7 hosts (RasPi, etc.)
Does this mean that now, we will be able to program in Swift on Raspberry Pi? |
Thanks Dmitri! I appreciate all of your comments! We're getting close, Trevor. Swiftc can make executable files, but there is a remaining problem in the linker part of the process, so they can't run just yet. |
Arguments.push_back( | ||
context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld")); | ||
|
||
// FIXME: This should also query the abi type (i.e. gnueabihf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hpux735 @gribozavr Sorry if I'm missing something, but would something like the following work?
diff --git a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
index 712ea65..872843a 100644
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -1115,10 +1115,11 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
// Add the linker script that coalesces protocol conformance sections.
Arguments.push_back("-Xlinker");
Arguments.push_back("-T");
-
- // FIXME: This should also query the abi type (i.e. gnueabihf)
+
Arguments.push_back(context.Args.MakeArgString(
- Twine(RuntimeLibPath) + "/" + getTriple().getArchName() + "/swift.ld"));
+ Twine(RuntimeLibPath) + "/" + getTriple().getArchName() + \
+ llvm::Triple::getEnvironmentTypeName(getTriple().getEnvironment()) + \
+ "/swift.ld"));
// This should be the last option, for convenience in checking output.
Arguments.push_back("-o");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, with a dash in between.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome. I'll send a pull request; there's also a test that needs updating.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you’ll need to update the location where the stdlib is built into, otherwise the paths won’t match. I tried this last night.
On Dec 14, 2015, at 7:25 AM, Brian Gesiak notifications@github.com wrote:
In lib/Driver/ToolChains.cpp #439 (comment):
@@ -1115,8 +1115,10 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
// Add the linker script that coalesces protocol conformance sections.
Arguments.push_back("-Xlinker");
Arguments.push_back("-T");
- Arguments.push_back(
context.Args.MakeArgString(Twine(RuntimeLibPath) + "/x86_64/swift.ld"));
- // FIXME: This should also query the abi type (i.e. gnueabihf)
Awesome. I'll send a pull request; there's also a test that needs updating.—
Reply to this email directly or view it on GitHub https://github.com/apple/swift/pull/439/files#r47509595.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, gotcha. Looks like it isn't as simple as I thought in #536, then. 😛
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good idea, but there's just one more piece to the puzzle. :)
@petevine I've finally finished a downloadable package for a working (but still very alpha) swift compiler and Foundation for ARM: http://www.housedillon.com/?p=2287 |
Thanks, I'll give it a try on my Odroid. EDIT:
What variables can be set to provide (presumably) the correct search paths? |
I didn't get the exact same error message, but it doesn't work for me, either. |
No problem if it's a bug and not user error. Depending on the absence/presence of
after unpacking your distro in /tmp |
I think it’s just as likely that I don’t know how to make the distribution package correctly. Joe Bell is looking into making a debian repository for publishing this. Hopefully he’s able to make that work a little better. I definitely like having things in the issue tracker. Even if it ends up being user error, no worries, it can just be closed. Otherwise, I’m very likely to forget all the different little issues that people mention to me. The latter is a much worse outcome! :)
|
@petevine Try out the package just posted at http://dev.iachieved.it/iachievedit/debian-packages-for-swift-on-arm/, both snippets of Swift code at the bottom of the post work on BeagleBone Black and BeagleBoard X15. I need to run out and get me a RaspPi 2, oddly enough I don't own one yet. |
I'll need a direct link as I'm not interested in installing system-wide. Thx. |
You can use
|
Thx, that's exactly what I had in mind. I'll let you know as soon as I've tried it out. EDIT: |
Yah, I’m very confused. I can’t reproduce this bug. On my fresh install (are you using Ubuntu or Debian?), it works fine when I install at /opt/apple. The file you’re seeing in /tmp is generated by the build process. A huge part of the swift build process is clang. Can you paste in your source code, just in case?
|
It's Ubuntu 14.04 so that probably means clang is not getting installed correctly. Code is just one line: Could you paste your Mine looks like this:
|
@petevine I am on Ubuntu 14.04 as well, here is my version of Clang and
Of course I can't reproduce your issue either, and I've installed the package on 3 different ARM systems, all armv7l based. |
The only apparent difference is gcc 4.9 on my system. Could you attach a strace from a successful compilation? |
Yep, sure thing: http://ramone.coas.oregonstate.edu/hello.trace |
I'm fairly certain that this is a duplicate of this bug: https://bugs.swift.org/browse/SR-23 and is not an Arm specific thing. |
@hpux735 That's definitely not a successful compilation! (source file didn't exist) If the issue is not ARM-specific, never mind - I'll have a go at swift when it's ready. |
Oops. I updated it. Also note that I don’t think that it’s tracing the clang invocation. That’s likely where the issue really is.
|
I'm almost finished with enabling native compilation on ARMv7 hosts such as the Raspberry Pi, BeagleBone, Nvidia Tegras, etc...
The build of the swift compiler and standard library complete. The compiler is also capable of generating executables, though there is a remaining linker problem. I'm not sure where to move from here, so I'm hoping that this work can be a starting point for some. The error is: unexpected reloc type 0x03
I've tested this patch in attempt to determine whether it negatively effects building on MacOS or Ubuntu 15.10 on x68_64. In MacOS, the test suite completes with 2 unexpected failures, 2350 expected passes, 5 expected failures, and 33 unsupported tests. The x86_64 linux build completes with 1682 expected passes, 92 expected failures, 575 unsupported failures (apparently no unexpected failures). Finally, the linux arm port completes the testing suite with 1456 expected passes, 81 expected failures, 639 unsupported tests, and 155 unexpected failures.
I'm happy to make any changes to requested, and I'd be overjoyed if anyone had a crumb trail I could follow to address the linking issued.
Any comments are very appreciated!