Skip to content

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

Merged
merged 7 commits into from
Dec 18, 2015
Merged

Adding support for ARMv7 on linux #159

merged 7 commits into from
Dec 18, 2015

Conversation

hpux735
Copy link
Contributor

@hpux735 hpux735 commented Dec 18, 2015

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)

sdk = OSType.MacOSX
arch = ArchType.x86_64
sdk = OSType.UnknownOS
arch = ArchType.UnknownArch
executable_suffix = ""
dynamic_library_prefix = "lib"
dynamic_library_suffix = ".dylib"
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

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"
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

@phausler
Copy link
Contributor

during the build it seems that it is spewing out a warning

[174/176] CompileSwift: Foundation/NSURLError.swift
<unknown>:0: warning: argument unused during compilation: '-mcpu=cortex-a15'

Is this because I am missing some other commit from the compiler?

@hpux735
Copy link
Contributor Author

hpux735 commented Dec 18, 2015

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.

@phausler
Copy link
Contributor

That warning was actually from a x86_64 host building for a x86_64 target; ubuntu 14

@hpux735
Copy link
Contributor Author

hpux735 commented Dec 18, 2015

It's nice that the compiler was smart enough to ignore obviously contradictory information! :)

@phausler
Copy link
Contributor

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.

phausler added a commit that referenced this pull request Dec 18, 2015
Adding support for ARMv7 on linux
@phausler phausler merged commit aa25b1c into swiftlang:master Dec 18, 2015
@hpux735
Copy link
Contributor Author

hpux735 commented Dec 18, 2015

Yep, that's totally expected. Thanks!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants