-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Adding support for ARMv7 on linux #159
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
Conversation
sdk = OSType.MacOSX | ||
arch = ArchType.x86_64 | ||
sdk = OSType.UnknownOS | ||
arch = ArchType.UnknownArch | ||
executable_suffix = "" | ||
dynamic_library_prefix = "lib" | ||
dynamic_library_suffix = ".dylib" |
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.
these are now incorrect if the sdk and arch are defaulted to unknown
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 I added the appropriate logic to compensate below. The only issue I have with setting default values is that it increased the time it took to identify the logic bug that "ArchType.from_string(comps[0])" wasn't actually assigning anything, it was essentially a no-op. The default value made it look like everything was fine, just wrong.
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.
fair point; I agree having an opinion about a "default" target is probably incorrect in a general sense. Just was thinking that perhaps it might be good to have these as None or some other thing to avoid any potential other trip-ups
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.
Good call. I'll do that.
if platform.system() == "Linux": | ||
triple += "linux-gnu" | ||
if arch == ArchType.arm: | ||
triple += "-linux-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.
what about "-linux-armeabi" or "-linux-android" etc? I know these are other handled cases in llvm's triple calculations
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.
Yes, I don't know the best way to handle that. Do you know a good way to detect what that part of the triple should be?
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.
See http://clang.llvm.org/docs/CrossCompilation.html
arch = x86, arm, thumb, mips, etc.
sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
vendor = pc, apple, nvidia, ibm, etc.
sys = none, linux, win32, darwin, cuda, etc.
abi = eabi, gnu, android, macho, elf, etc.
So we probably need another field since triples are not three parts and instead five parts with three reasonably optional fields.
arch[sub][-vendor]-sys[-abi]
However this method is the script's host not the target. So I am not certain which hosts we want to really support here.
during the build it seems that it is spewing out a warning
Is this because I am missing some other commit from the compiler? |
There is a compiler issue at play there, but it isn't resolved yet. I backed it out. I expect that you'll see several ":0: warning: unknown platform, assuming -mfloat-abi=soft" if you are running on an arm platform. |
That warning was actually from a x86_64 host building for a x86_64 target; ubuntu 14 |
It's nice that the compiler was smart enough to ignore obviously contradictory information! :) |
full clean build for the entire toolchain + foundation seems to pass just fine on ubuntu and on mac os x; the only caveat here is that this falls under the same domain as the FreeBSD port in that this is not a regularly tested path so there may be things that break since we won't be testing there. |
Adding support for ARMv7 on linux
Yep, that's totally expected. Thanks!! |
These changes begin support for ARMv7 and linux. There are a few optimizations yet to be completed (it's falling back to soft floating point), and there seems to be assumptions about the size of ssize made in some swift code. (for example: Foundation/NSXMLParser.swift:238)