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

Add Fuchsia OS support #12955

Open
wants to merge 12 commits into
base: master
from

Conversation

@zbowling
Contributor

zbowling commented Nov 16, 2017

Adds initial support for Fuchsia OS to the compiler and adds support for building for Fuchsia in the stdlib.

This change also introduces lld linker support to the build system and fixes a number of issues related to cross compiling Swift to platforms that do not support universal binaries. As part of this change, non-Darwin libraries in the standard library are now stored in lib/swift/<platform>/<arch> instead of lib/swift/<platform>.

@@ -68,7 +68,7 @@ Driver::Driver(StringRef DriverExecutable,
: Opts(createSwiftOptTable()), Diags(Diags),
Name(Name), DriverExecutable(DriverExecutable),
DefaultTargetTriple(llvm::sys::getDefaultTargetTriple()) {

This comment has been minimized.

@slavapestov

slavapestov Nov 16, 2017

Member

Can you separate the whitespace changes into a separate commit?

@slavapestov

slavapestov Nov 16, 2017

Member

Can you separate the whitespace changes into a separate commit?

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

sure thing :)

@zbowling

zbowling Nov 16, 2017

Contributor

sure thing :)

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

I split the commit into two changes now

@zbowling

zbowling Nov 16, 2017

Contributor

I split the commit into two changes now

This comment has been minimized.

@AfridiShahriar

AfridiShahriar Nov 20, 2017

Hey what's ur plan with the fushciaOS? Will it replace Android? Or, be another platform?

@AfridiShahriar

AfridiShahriar Nov 20, 2017

Hey what's ur plan with the fushciaOS? Will it replace Android? Or, be another platform?

This comment has been minimized.

@zbowling

zbowling Nov 21, 2017

Contributor

Sorry, I'm not qualified to speak to that and it's little off-topic for this PR.

@zbowling

zbowling Nov 21, 2017

Contributor

Sorry, I'm not qualified to speak to that and it's little off-topic for this PR.

@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 16, 2017

Contributor

FYI, in the pipeline after this we will have some PRs related to:

  • adding ARM64 support for the Fuchsia SDK
  • fixing cross-compiling issues for targeting BSD, Linux and Fuchsia targets from a Darwin toolchain
  • adding support for using lld for linking specific SDK stdlibs (part of getting a Darwin toolchain capable of cross compiling to other targets)
  • supporting unit tests on Fuchsia
Contributor

zbowling commented Nov 16, 2017

FYI, in the pipeline after this we will have some PRs related to:

  • adding ARM64 support for the Fuchsia SDK
  • fixing cross-compiling issues for targeting BSD, Linux and Fuchsia targets from a Darwin toolchain
  • adding support for using lld for linking specific SDK stdlibs (part of getting a Darwin toolchain capable of cross compiling to other targets)
  • supporting unit tests on Fuchsia
Show outdated Hide outdated lib/Driver/ToolChains.cpp Outdated
@@ -1781,6 +1803,14 @@ bool toolchains::Android::shouldProvideRPathToLinker() const {
return false;
}
std::string toolchains::Fuchsia::getDefaultLinker() const {
return "lld";

This comment has been minimized.

@petrhosek

petrhosek Nov 16, 2017

This should be "ld.lld".

@petrhosek

petrhosek Nov 16, 2017

This should be "ld.lld".

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

Fix in flight. I thought "-fuse-ld=ld.lld" looked funnier than "-fuse-ld=lld" that swift invokes on clang.

@zbowling

zbowling Nov 16, 2017

Contributor

Fix in flight. I thought "-fuse-ld=ld.lld" looked funnier than "-fuse-ld=lld" that swift invokes on clang.

This comment has been minimized.

@petrhosek

petrhosek Nov 16, 2017

Ah, if this is what Swift passes to -fuse-ld= then "lld" is correct, if this is the name of the binary that Swift will invoke then it should be "ld.lld" (I haven't looked at how this is wired up internally).

@petrhosek

petrhosek Nov 16, 2017

Ah, if this is what Swift passes to -fuse-ld= then "lld" is correct, if this is the name of the binary that Swift will invoke then it should be "ld.lld" (I haven't looked at how this is wired up internally).

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

yeah it's for -fuse-ld

@zbowling

zbowling Nov 16, 2017

Contributor

yeah it's for -fuse-ld

@@ -111,6 +111,16 @@ class LLVM_LIBRARY_VISIBILITY Android : public GenericUnix {
~Android() = default;
};
class LLVM_LIBRARY_VISIBILITY Fuchsia : public GenericUnix {

This comment has been minimized.

@petrhosek

petrhosek Nov 16, 2017

This is what we originally did in Clang as well, but it was causing more issues than solving since Fuchsia really isn't UNIX, so we since moved to inheriting directly from the ToolChain class, that's something to consider.

@petrhosek

petrhosek Nov 16, 2017

This is what we originally did in Clang as well, but it was causing more issues than solving since Fuchsia really isn't UNIX, so we since moved to inheriting directly from the ToolChain class, that's something to consider.

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

Yeah, right now there isn't too much friction pretending Fuchsia is a type of "Unix" for at least the args used by Swift to drive clang/ld (Fuchsia is an elf platform but not a Unix, even though it has some posix-y looking things).

It might make sense to make a base class that both GenericUnix and Fuchsia's toolchain class inherit called ElfPlatform or something maybe and move things around.

We have a similar friction with the name of the Glibc module (we aren't using "GNU Glibc" but it's the name that existing code assumes the libc module is called outside of Darwin). I'm hoping people will use our platform libc module map instead there even though the Glibc module works right now too.

@zbowling

zbowling Nov 16, 2017

Contributor

Yeah, right now there isn't too much friction pretending Fuchsia is a type of "Unix" for at least the args used by Swift to drive clang/ld (Fuchsia is an elf platform but not a Unix, even though it has some posix-y looking things).

It might make sense to make a base class that both GenericUnix and Fuchsia's toolchain class inherit called ElfPlatform or something maybe and move things around.

We have a similar friction with the name of the Glibc module (we aren't using "GNU Glibc" but it's the name that existing code assumes the libc module is called outside of Darwin). I'm hoping people will use our platform libc module map instead there even though the Glibc module works right now too.

Show outdated Hide outdated stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb Outdated
Show outdated Hide outdated stdlib/public/stubs/Stubs.cpp Outdated
Show outdated Hide outdated CMakeLists.txt Outdated
Show outdated Hide outdated CMakeLists.txt Outdated
@gottesmm

This PR has a bunch of really large changes in it. It really should be split up at least into multiple commits, but perhaps into multiple PRs. That will make it easier to review. I provided several examples of places that I think that you could split off into separate commits/PRs.

@@ -1968,6 +1980,17 @@ for host in "${ALL_HOSTS[@]}"; do
-DCMAKE_SHARED_LINKER_FLAGS:STRING="-fuse-ld=gold"
)
fi
elif [[ "${USE_LLD_LINKER}" ]]; then

This comment has been minimized.

@gottesmm

gottesmm Nov 16, 2017

Member

Can you split the LLD change into a separate PR. That should be able to stand on its own.

@gottesmm

gottesmm Nov 16, 2017

Member

Can you split the LLD change into a separate PR. That should be able to stand on its own.

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

Yeah, that is the easiest to pull out.

@zbowling

zbowling Nov 16, 2017

Contributor

Yeah, that is the easiest to pull out.

@@ -436,7 +440,10 @@ function set_build_options_for_host() {
linux-*)
SWIFT_HOST_VARIANT="linux"
SWIFT_HOST_VARIANT_SDK="LINUX"
USE_GOLD_LINKER=1
if [[ -z "${USE_LLD_LINKER}" ]] ; then

This comment has been minimized.

@gottesmm

gottesmm Nov 16, 2017

Member

Can you split the build-script changes into a separate commit.

@gottesmm

gottesmm Nov 16, 2017

Member

Can you split the build-script changes into a separate commit.

Show outdated Hide outdated CMakeLists.txt Outdated
Show outdated Hide outdated lib/ClangImporter/ClangImporter.cpp Outdated
@@ -14,7 +14,7 @@
//
//===----------------------------------------------------------------------===//
#if defined(__CYGWIN__) || defined(__ANDROID__) || defined(_WIN32) || defined(__HAIKU__)
#if defined(__CYGWIN__) || defined(__ANDROID__) || defined(_WIN32) || defined(__Fuchsia__) || defined(__HAIKU__)

This comment has been minimized.

@gottesmm

gottesmm Nov 16, 2017

Member

Can you separate this out as well.

@gottesmm

gottesmm Nov 16, 2017

Member

Can you separate this out as well.

Show outdated Hide outdated cmake/modules/AddSwift.cmake Outdated
Show outdated Hide outdated cmake/modules/AddSwift.cmake Outdated
import Glibc
#endif
#if !os(Windows)
// posix_spawn is not available on Windows.
// posix_spawn is not available on Android.
// posix_spawn is not available on Fuchsia. (TODO: Fuchsia provides liblaunchpad for this)

This comment has been minimized.

@modocache

modocache Nov 16, 2017

Collaborator

nit-pick: Maybe we could put all of these comments on a single line? posix_spawn is not available on Windows, Android, Haiku, or Fuchsia.? It just seems a little excessive to have four lines of comments here, IMHO :)

@modocache

modocache Nov 16, 2017

Collaborator

nit-pick: Maybe we could put all of these comments on a single line? posix_spawn is not available on Windows, Android, Haiku, or Fuchsia.? It just seems a little excessive to have four lines of comments here, IMHO :)

This comment has been minimized.

@gparker42

gparker42 Nov 16, 2017

Member

There should be at least two lines, because the Windows case is unlike the others. If I'm reading it correctly this !Windows check covers the entire file, not just the spawn vs fork/exec distinction. In any case such cleanup shouldn't be the job of this change.

@gparker42

gparker42 Nov 16, 2017

Member

There should be at least two lines, because the Windows case is unlike the others. If I'm reading it correctly this !Windows check covers the entire file, not just the spawn vs fork/exec distinction. In any case such cleanup shouldn't be the job of this change.

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

Yeah a lot of this is to just to get it compiling. Some of the functions in Subprocess.swift are defined in our libc today for compatibility but not not actually backed by a real implementation. Basically, how you create, manage, and communicate with a child process is something that Fuchsia really departs heavily from compared to how any other Unix clone out there works today. So for Subprocess.swift we will have to do something a lot different. I was going to land our implementation of this later as we start bringing up some of the unit tests and get them running on device though.

For background reference, on Fuchsia we don't have fork or posix_spawn equivalents and we don't use dup'd fds to communicate with child processes (although you can do something like that to work with your child's stdin/out). Instead you ask the system to create you a process via a syscall and then it's up to you load everything your child process needs into it's memory via shared memory object. Then when you are done you use another syscall to ask the system to start a thread on that process for you. We have a convenience library that makes this easier but it doesn't really end up looking anything like posix_spawn or fork/exec.

@zbowling

zbowling Nov 16, 2017

Contributor

Yeah a lot of this is to just to get it compiling. Some of the functions in Subprocess.swift are defined in our libc today for compatibility but not not actually backed by a real implementation. Basically, how you create, manage, and communicate with a child process is something that Fuchsia really departs heavily from compared to how any other Unix clone out there works today. So for Subprocess.swift we will have to do something a lot different. I was going to land our implementation of this later as we start bringing up some of the unit tests and get them running on device though.

For background reference, on Fuchsia we don't have fork or posix_spawn equivalents and we don't use dup'd fds to communicate with child processes (although you can do something like that to work with your child's stdin/out). Instead you ask the system to create you a process via a syscall and then it's up to you load everything your child process needs into it's memory via shared memory object. Then when you are done you use another syscall to ask the system to start a thread on that process for you. We have a convenience library that makes this easier but it doesn't really end up looking anything like posix_spawn or fork/exec.

@@ -84,7 +85,7 @@ public func spawnChild(_ args: [String])
let childStdin = posixPipe()
let childStderr = posixPipe()
#if os(Android) || os(Haiku)
#if os(Android) || os(Haiku) || os(Fuchsia)

This comment has been minimized.

@modocache

modocache Nov 16, 2017

Collaborator

The comment immediately below this could use some updating, since it's not just a codepath taken by Android anymore.

@modocache

modocache Nov 16, 2017

Collaborator

The comment immediately below this could use some updating, since it's not just a codepath taken by Android anymore.

@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 16, 2017

Contributor

Yeah sorry about the big PR. I squashed all my commits from before I got approval to upstream.

I think can split this PR into 3 different parts that would still be viable and testable on their own. I think it makes sense to break it into:

  • lld support (mostly build-util and cmake changes)
  • fixes for the mutli-arch cross compiling issues (mostly cmake changes and some compiler changes to change where it looks for libs)
  • adding the Fuchsia target support (still making changes all over but it should be a smaller patch)

After that I send up additional things as separate PRs that I listed perviously. That work?

Contributor

zbowling commented Nov 16, 2017

Yeah sorry about the big PR. I squashed all my commits from before I got approval to upstream.

I think can split this PR into 3 different parts that would still be viable and testable on their own. I think it makes sense to break it into:

  • lld support (mostly build-util and cmake changes)
  • fixes for the mutli-arch cross compiling issues (mostly cmake changes and some compiler changes to change where it looks for libs)
  • adding the Fuchsia target support (still making changes all over but it should be a smaller patch)

After that I send up additional things as separate PRs that I listed perviously. That work?

@gottesmm

This comment has been minimized.

Show comment
Hide comment
@gottesmm

gottesmm Nov 16, 2017

Member

SGTM

Member

gottesmm commented Nov 16, 2017

SGTM

@gribozavr

This comment has been minimized.

Show comment
Hide comment
@gribozavr

gribozavr Nov 16, 2017

Collaborator

Could you add tests like these:

test/Parse/ConditionalCompilation/x64FreeBSDTarget.swift
validation-test/StdlibUnittest/FreeBSD.swift

It would be also great to add some docs about running the build like docs/Android.md.

Collaborator

gribozavr commented Nov 16, 2017

Could you add tests like these:

test/Parse/ConditionalCompilation/x64FreeBSDTarget.swift
validation-test/StdlibUnittest/FreeBSD.swift

It would be also great to add some docs about running the build like docs/Android.md.

@gottesmm

This comment has been minimized.

Show comment
Hide comment
@gottesmm

gottesmm Nov 16, 2017

Member

Whoah! Its a wild @gribozavr! Waves!

Member

gottesmm commented Nov 16, 2017

Whoah! Its a wild @gribozavr! Waves!

Show outdated Hide outdated lib/Driver/ToolChains.cpp Outdated
@@ -2028,6 +2051,12 @@ for host in "${ALL_HOSTS[@]}"; do
"${llvm_cmake_options[@]}"
)
if [[ "${USE_LLD_LINKER}" ]]; then
cmake_options+=(
-DLLVM_ENABLE_LLD:BOOL=YES

This comment has been minimized.

@gribozavr

gribozavr Nov 16, 2017

Collaborator

Missing indentation?

@gribozavr

gribozavr Nov 16, 2017

Collaborator

Missing indentation?

This comment has been minimized.

@zbowling

zbowling Nov 16, 2017

Contributor

woops. yep.

@zbowling

zbowling Nov 16, 2017

Contributor

woops. yep.

This comment has been minimized.

@zbowling

zbowling Nov 21, 2017

Contributor

looks like that bad indentation was used in other places too. I'll fix it everywhere in an upcoming CL.

@zbowling

zbowling Nov 21, 2017

Contributor

looks like that bad indentation was used in other places too. I'll fix it everywhere in an upcoming CL.

Show outdated Hide outdated stdlib/public/stubs/GlobalObjects.cpp Outdated
Show outdated Hide outdated stdlib/public/stubs/GlobalObjects.cpp Outdated
@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 16, 2017

Contributor

Yeah, I may add a Fuchsia.md doc to docs folder. I think it makes sense to just document the current args on build-util and then link to Fuchsia's doc repo for how to use swift since things are constantly changing in Fuchsia. At some point I soon I would love to get things working with swiftpm.

Contributor

zbowling commented Nov 16, 2017

Yeah, I may add a Fuchsia.md doc to docs folder. I think it makes sense to just document the current args on build-util and then link to Fuchsia's doc repo for how to use swift since things are constantly changing in Fuchsia. At some point I soon I would love to get things working with swiftpm.

@gribozavr

This comment has been minimized.

Show comment
Hide comment
@gribozavr

gribozavr Nov 16, 2017

Collaborator

Right, it does not have to be perfect, but it would ideally contain end-to-end instructions on how to compile Swift for the platform: what are the prerequisites, what is the expected filesystem layout that you need to prepare, how to run build-script, how to run tests for the host side and the device side.

Collaborator

gribozavr commented Nov 16, 2017

Right, it does not have to be perfect, but it would ideally contain end-to-end instructions on how to compile Swift for the platform: what are the prerequisites, what is the expected filesystem layout that you need to prepare, how to run build-script, how to run tests for the host side and the device side.

@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 16, 2017

Contributor

I broke up the PR into 5 separate commits and fixed a number of things mentioned here. I will land another commit to fix where we are hardcoding paths in the Fuchsia tree and replace with them build-util configurable options shortly.

Contributor

zbowling commented Nov 16, 2017

I broke up the PR into 5 separate commits and fixed a number of things mentioned here. I will land another commit to fix where we are hardcoding paths in the Fuchsia tree and replace with them build-util configurable options shortly.

@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 16, 2017

Contributor

I just realized one of the earlier commits I broke up makes a reference to a cmake variable that is introduced in a later commit so they are not perfectly hermetic.

Contributor

zbowling commented Nov 16, 2017

I just realized one of the earlier commits I broke up makes a reference to a cmake variable that is introduced in a later commit so they are not perfectly hermetic.

@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 17, 2017

Contributor

@swift-ci Please smoke test

Contributor

zbowling commented Nov 17, 2017

@swift-ci Please smoke test

@phausler

This comment has been minimized.

Show comment
Hide comment
@phausler

phausler Nov 17, 2017

Member

@swift-ci please smoke test

Member

phausler commented Nov 17, 2017

@swift-ci please smoke test

Show outdated Hide outdated lib/Driver/ToolChains.cpp Outdated
@compnerd

This comment has been minimized.

Show comment
Hide comment
@compnerd

compnerd Nov 18, 2017

Collaborator

@zbowling I think it would be better to create separate PRs for thee commits. I dont see why we should wait for the whitespace cleanups. I think that the lld support change can probably go in earlier as well. Reducing the outstanding patches is probably a good idea.

Collaborator

compnerd commented Nov 18, 2017

@zbowling I think it would be better to create separate PRs for thee commits. I dont see why we should wait for the whitespace cleanups. I think that the lld support change can probably go in earlier as well. Reducing the outstanding patches is probably a good idea.

@@ -106,12 +106,36 @@ swift::_SwiftEmptySetStorage swift::_swiftEmptySetStorage = {
0 // int entries; (zero'd bits)
};
#if defined(__Fuchsia__)
#include <zircon/syscalls.h>
static __swift_uint64_t randomUInt64() {

This comment has been minimized.

@petrhosek

petrhosek Nov 23, 2017

This should be using getentropy which is provided by Fuchsia's libc, not zx_cprng_draw which is a syscall and considered to be implementation detail.

@petrhosek

petrhosek Nov 23, 2017

This should be using getentropy which is provided by Fuchsia's libc, not zx_cprng_draw which is a syscall and considered to be implementation detail.

This comment has been minimized.

@zbowling

zbowling Nov 23, 2017

Contributor

Yeah, I wrote this before that was implemented and had our security guys give me an ok. Our getentropy function ends up doing nearly the same thing (except this has some protection if we actually read was less than requested). I was going to wait for TO-460 was finished and then we can just use std::random_device like every other arch in this ifdef.

@zbowling

zbowling Nov 23, 2017

Contributor

Yeah, I wrote this before that was implemented and had our security guys give me an ok. Our getentropy function ends up doing nearly the same thing (except this has some protection if we actually read was less than requested). I was going to wait for TO-460 was finished and then we can just use std::random_device like every other arch in this ifdef.

@@ -122,6 +124,9 @@ macro(configure_sdk_darwin
set(SWIFT_SDK_${prefix}_OBJECT_FORMAT "MACHO")
foreach(arch ${architectures})
# On Darwin, all archs share the same SDK path.
set(SWIFT_SDK_${prefix}_ARCH_${arch}_PATH "${SWIFT_SDK_${prefix}_PATH}")

This comment has been minimized.

@zbowling

zbowling Nov 23, 2017

Contributor

Having SWIFT_SDK_${prefix}_PATH as the only variable works for Darwin since the SDK has all the archs compiled and lipo'd together in a single directory but other platforms have arch specific sysroot paths. This assumption was limiting other Unix SDKs to only supporting one arch at time. I fixed it here. For Darwin each arch specific SDK path actually just points to the same path.

@zbowling

zbowling Nov 23, 2017

Contributor

Having SWIFT_SDK_${prefix}_PATH as the only variable works for Darwin since the SDK has all the archs compiled and lipo'd together in a single directory but other platforms have arch specific sysroot paths. This assumption was limiting other Unix SDKs to only supporting one arch at time. I fixed it here. For Darwin each arch specific SDK path actually just points to the same path.

@jrose-apple

Assorted comments from me. I'd also like to be sure someone outside Fuchsia is willing to sign off on the CMake and build-script changes. @Rostepher and @modocache are good candidates.

echo "${product}: using lld linker"
if [[ "${product}" != "swift" ]]; then
# All other projects override the linker flags to add in
# lld linker support.

This comment has been minimized.

@jrose-apple

jrose-apple Nov 27, 2017

Member

Does this include LLVM/Clang too? Seems like those should support LLVM_ENABLE_LLD.

@jrose-apple

jrose-apple Nov 27, 2017

Member

Does this include LLVM/Clang too? Seems like those should support LLVM_ENABLE_LLD.

This comment has been minimized.

@zbowling

zbowling Nov 28, 2017

Contributor

Those are getting by with the LLVM_ENABLE_LLD flag. This is doing the same logic we do for -fuse-ld=gold above.

@zbowling

zbowling Nov 28, 2017

Contributor

Those are getting by with the LLVM_ENABLE_LLD flag. This is doing the same logic we do for -fuse-ld=gold above.

Show outdated Hide outdated utils/build_swift/driver_arguments.py Outdated
Show outdated Hide outdated cmake/modules/AddSwift.cmake Outdated
Show outdated Hide outdated lib/Driver/ToolChains.cpp Outdated
@@ -1689,6 +1708,7 @@ toolchains::GenericUnix::constructInvocation(const LinkJobAction &job,
Arguments.push_back(context.Args.MakeArgString(StaticRuntimeLibPath));
SmallString<128> linkFilePath = StaticRuntimeLibPath;
llvm::sys::path::remove_filename(linkFilePath); // remove arch name
llvm::sys::path::append(linkFilePath, "static-executable-args.lnk");

This comment has been minimized.

@jrose-apple

jrose-apple Nov 27, 2017

Member

Are these not arch-specific?

@jrose-apple

jrose-apple Nov 27, 2017

Member

Are these not arch-specific?

This comment has been minimized.

@zbowling

zbowling Nov 27, 2017

Contributor

They currently are not. I could see them possibly being arch specific but right now we use the same libraries everywhere.

static-executable and static-library are a little busted though and do some squirrely stuff. Some of the libs end up getting doubled in the linker script and with static-executable it ends up linking in all symbols and not allowing the linker to strip at all which ends up making huge binaries unnecessarily. Was going to poke this in a later commit because it doesn't seem to being doing anything too useful for Linux right now and it's something we will probably want on Fuchsia.

@zbowling

zbowling Nov 27, 2017

Contributor

They currently are not. I could see them possibly being arch specific but right now we use the same libraries everywhere.

static-executable and static-library are a little busted though and do some squirrely stuff. Some of the libs end up getting doubled in the linker script and with static-executable it ends up linking in all symbols and not allowing the linker to strip at all which ends up making huge binaries unnecessarily. Was going to poke this in a later commit because it doesn't seem to being doing anything too useful for Linux right now and it's something we will probably want on Fuchsia.

Show outdated Hide outdated lib/ClangImporter/ClangImporter.cpp Outdated
Show outdated Hide outdated stdlib/public/Platform/CMakeLists.txt Outdated
Show outdated Hide outdated stdlib/public/Platform/CMakeLists.txt Outdated
Show outdated Hide outdated stdlib/public/runtime/ImageInspectionELF.cpp Outdated
Show outdated Hide outdated lib/Frontend/CompilerInvocation.cpp Outdated
@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Nov 28, 2017

Contributor

I separated this PR out into five separate PRs. This one specifically, adding Fuchsia support, is dependent on the other four for the Fuchsia port to function properly. The other PRs should work on their own and independently of each other.

I also cleaned up, squashed, split, and cleaned up the commits on this branch for the PR split.

Contributor

zbowling commented Nov 28, 2017

I separated this PR out into five separate PRs. This one specifically, adding Fuchsia support, is dependent on the other four for the Fuchsia port to function properly. The other PRs should work on their own and independently of each other.

I also cleaned up, squashed, split, and cleaned up the commits on this branch for the PR split.

@zbowling zbowling changed the title from Add Fuchsia OS and lld linker support to Add Fuchsia OS support Nov 28, 2017

zbowling added some commits Nov 16, 2017

Add LLD linker option to build-script
Allows compiling swift, clang, llvm, etc with lld instead of gold on
Linux and cross compile targets.
Fix multi-arch cross-compiling
On platforms without fat binaries (anything but Darwin), we now build
and install stdlibs for each arch in it's own folder. Namely
lib/swift/<platform>/<arch> instead of lib/swift/<platform>.
@zbowling

This comment has been minimized.

Show comment
Hide comment
@zbowling

zbowling Dec 5, 2017

Contributor

This branch was getting stale waiting to merge all the other PRs so I rebased it on the progress in those our PRs and merged all my changes from master including porting over to the new build script driver arguments format.

Contributor

zbowling commented Dec 5, 2017

This branch was getting stale waiting to merge all the other PRs so I rebased it on the progress in those our PRs and merged all my changes from master including porting over to the new build script driver arguments format.

zbowling added some commits Nov 28, 2017

Add Fuchsia OS Support
Adds Fuchsia target support to the compiler and builds the stdlib for
Fuchsia.
Define _GNU_SOURCE when importing glibc on Fuchisa
Some functions and types are hidden behind feature flags.

_GNU_SOURCE exposes the most symbols and methods in glibc
and musl. Currently only turning it on for the Fuchsia triple.

Also add a test for the missing extended C functions in the Glibc
module.

@Dev1an Dev1an referenced this pull request Dec 10, 2017

Closed

Swift 4.0 Status #5

@zakrid

This comment has been minimized.

Show comment
Hide comment
@zakrid

zakrid Apr 27, 2018

any updates to this PR? very interesting to see the work being done here

zakrid commented Apr 27, 2018

any updates to this PR? very interesting to see the work being done here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment