This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes#552
Explicitly have the only C++ portion of the runtime be one file with exception
handling. All other runtime files must now live in C and be fully defined in C.
- remove /usr/include from the include path since the iOS SDK provides the correct version
- `_NSGetEnviron()` is private and not available on iOS
- `.align` without an argument is not allowed with the Apple tools. 2^2 should be the default alignment
- ignore error messages for XCode < 5
- pass include path to libuv
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
This commit resumes management of the stack boundaries and limits when switching
between tasks. This additionally leverages the __morestack function to run code
on "stack overflow". The current behavior is to abort the process, but this is
probably not the best behavior in the long term (for deails, see the comment I
wrote up in the stack exhaustion routine).
This change adds -Z soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.
This patch fixes some errors of MIPS target, however, MIPS C ABI is still broken. I will send another PR to fix the problem.
Because MIPS target has no "generic" CPU name, I add --target-cpu and --target-feature to RUST_FLAGS. In order to workaround the "compact frame descriptions incompatible with DWARF2 .eh_frame" problem, the linker I used is CXX but not CC.
This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
We currently have no need for the frame pointers on any platform. They
may eventually be needed on platforms without an equivalent to the DWARF
call frame information to walk the stack in the garbage collector.
Closes#7477
It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.
