about summary refs log tree commit diff
path: root/src/librustc/back
AgeCommit message (Collapse)AuthorLines
2014-09-06mark win32 binaries as large address awareDaniel Micay-0/+6
By default, 32-bit Windows executables are restricted to 2GiB of address space even when running on 64-bit Windows when 4GiB is available. Closes #17043
2014-09-06auto merge of #16907 : SimonSapin/rust/tempdir-result, r=huonwbors-2/+2
This allows using `try!()` [breaking-change] Fixes #16875
2014-09-05don't use `ld -r` with `-C codegen-units=1`Stuart Pernsteiner-0/+12
2014-09-05add workaround for mingw `ld --force-exe-suffix` behaviorStuart Pernsteiner-1/+25
2014-09-05don't leave unwanted temporary files with --emit=ir/asmStuart Pernsteiner-3/+6
2014-09-05use target-specific linker args when combining compilation unitsStuart Pernsteiner-2/+19
2014-09-05run optimization and codegen on worker threadsStuart Pernsteiner-249/+691
Refactor the code in `llvm::back` that invokes LLVM optimization and codegen passes so that it can be called from worker threads. (Previously, it used `&Session` extensively, and `Session` is not `Share`.) The new code can handle multiple compilation units, by compiling each unit to `crate.0.o`, `crate.1.o`, etc., and linking together all the `crate.N.o` files into a single `crate.o` using `ld -r`. The later linking steps can then be run unchanged. The new code preserves the behavior of `--emit`/`-o` when building a single compilation unit. With multiple compilation units, the `--emit=asm/ir/bc` options produce multiple files, so combinations like `--emit=ir -o foo.ll` will not actually produce `foo.ll` (they instead produce several `foo.N.ll` files). The new code supports `-Z lto` only when using a single compilation unit. Compiling with multiple compilation units and `-Z lto` will produce an error. (I can't think of any good reason to do such a thing.) Linking with `-Z lto` against a library that was built as multiple compilation units will also fail, because the rlib does not contain a `crate.bytecode.deflate` file. This could be supported in the future by linking together the `crate.N.bc` files produced when compiling the library into a single `crate.bc`, or by making the LTO code support multiple `crate.N.bytecode.deflate` files.
2014-09-05move back::link::write into a separate fileStuart Pernsteiner-479/+482
2014-09-05split CrateContext into shared and local piecesStuart Pernsteiner-0/+1
Break up `CrateContext` into `SharedCrateContext` and `LocalCrateContext`. The local piece corresponds to a single compilation unit, and contains all LLVM-related components. (LLVM data structures are tied to a specific `LLVMContext`, and we will need separate `LLVMContext`s to safely run multithreaded optimization.) The shared piece contains data structures that need to be shared across all compilation units, such as the `ty::ctxt` and some tables related to crate metadata.
2014-09-05make CrateContext fields privateStuart Pernsteiner-4/+4
2014-09-03Fix spelling errors and capitalization.Joseph Crail-2/+2
2014-08-31Have std::io::TempDir::new and new_in return IoResultSimon Sapin-2/+2
This allows using `try!()` [breaking-change] Fixes #16875
2014-08-25auto merge of #16694 : vadimcn/rust/debug-linker, r=alexcrichtonbors-0/+2
Shows linker spew even when linking succeeds. This is occasionally useful in order to see verbose linker output.
2014-08-24Enable the MergeFunc passBjörn Steinbrink-0/+7
Fixes #9536
2014-08-23Log linker stderr and stdout.Vadim Chugunov-0/+2
2014-08-23Complete renaming of win32 to windowsVadim Chugunov-1/+1
2014-08-17mark Windows binaries as compatible with ASLRDaniel Micay-0/+3
This is enough for dynamic libraries, but not executables because MinGW does not output a .reloc section even with `--dynamicbase`. It could either be worked around by exporting a DLL symbol from the executable or fixed in MinGW itself.
2014-08-16enable DEP (NX bit) for 32-bit Windows executablesDaniel Micay-0/+3
This is already enabled by default for x86_64 executables on Windows, but it needs to be manually enabled on x86. Closes #16533
2014-08-12Replace all references to "Win32" with "Windows".Vadim Chugunov-7/+7
For historical reasons, "Win32" has been used in Rust codebase to mean "Windows OS in general". This is confusing, especially now, that Rust supports Win64 builds. [breaking-change]
2014-08-07enable PIE by default on Linux for full ASLRDaniel Micay-3/+15
Rust already builds all code as position independent by default, so the linker can be told to build a position independent executable if it's not disabled with `-C relocation-model=dynamic-no-pic`. Position independent code does have a significant cost on i686 (not on x86_64 or ARM) but there's no significant cost to linking code that's already position independent as a position independent executable. Address space layout randomization makes exploiting vulnerabilities much more difficult by providing a statistical defence against an attempt to find or modify existing code / data. Without ASLR, it's trivial to use a vulnerability to take over control of the process via return-oriented programming. Rust code can be used for return-oriented programming whether it is safe or unsafe, so even a fully safe application needs to be built as a position independent executable to defend against vulnerabilities in unsafe blocks or C libraries. Sample program: extern crate libc; use std::mem; static mut global: u32 = 5; static constant: u32 = 5; fn foo() {} fn main() { let local = 5; println!("stack: {}, global: {}, constant: {}, fn: {}, lib fn: {}", &local as *const u32, unsafe { &global as *const u32 }, &constant as *const u32, unsafe { mem::transmute::<_, *const ()>(foo) }, unsafe { mem::transmute::<_, *const ()>(libc::mprotect) }); } Before: stack: 0x3ff15eb9f94, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x32749547530 stack: 0x3b5d47d80e4, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x394469a7530 stack: 0x3fe2c4e5564, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x399734a2530 stack: 0x3e525e0fb24, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x2f62a810530 stack: 0x3b50fb3eae4, global: 0x6ab488, constant: 0x47db40, fn: 0x4030e0, lib fn: 0x2e590e86530 After: stack: 0x38cf12c90a4, global: 0x3e2d46b488, constant: 0x3e2d23cf80, fn: 0x3e2d1c2510, lib fn: 0x2617d3b4530 stack: 0x3d733faf474, global: 0x7eb1839488, constant: 0x7eb160af80, fn: 0x7eb1590510, lib fn: 0x32d30c1f530 stack: 0x3bb42212ec4, global: 0x5bbb365488, constant: 0x5bbb136f80, fn: 0x5bbb0bc510, lib fn: 0x3595e6c1530 stack: 0x39f678c1ab4, global: 0x22c4e3c488, constant: 0x22c4c0df80, fn: 0x22c4b93510, lib fn: 0x3835b727530 stack: 0x3afb25bd394, global: 0x493eab2488, constant: 0x493e883f80, fn: 0x493e809510, lib fn: 0x3478d6a7530 This may also be necessary on other platforms, but I can only test on Linux right now. Note that GDB gained support for debugging position independent executables in version 7.1 (March 2010).
2014-08-04rustc: Link entire archives of native librariesAlex Crichton-16/+49
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not actually guaranteed to link the library at all. The reason for this is that if the external library doesn't have any referenced symbols in the object generated by rustc, the entire library is dropped by the linker. For dynamic native libraries, this is solved by passing -lfoo for all downstream compilations unconditionally. For static libraries in rlibs this is solved because the entire archive is bundled in the rlib. The only situation in which this was a problem was when a static native library was linked to a rust dynamic library. This commit brings the behavior of dylibs in line with rlibs by passing the --whole-archive flag to the linker when linking native libraries. On OSX, this uses the -force_load flag. This flag ensures that the entire archive is considered candidate for being linked into the final dynamic library. This is a breaking change because if any static library is included twice in the same compilation unit then the linker will start emitting errors about duplicate definitions now. The fix for this would involve only statically linking to a library once. Closes #15460 [breaking-change]
2014-08-03Use a versioning scheme for bytecode objects in rlibs.Michael Woerister-38/+168
Before this commit, the LLVM IR of exported items was simply zip-compressed and stored as an object file inside rlib archives. This commit adds a header to this "object" containing a file identifier and a format version number so the compiler can deal with changes in the way bytecode objects are stored within rlibs. While updating the format of bytecode objects, this commit also worksaround a problem in LLDB which could not handle odd-sized objects within archives before mid-2014.
2014-07-31auto merge of #16073 : mneumann/rust/dragonfly2, r=alexcrichtonbors-1/+9
Not included are two required patches: * LLVM: segmented stack support for DragonFly [1] * jemalloc: simple configure patches [1]: http://reviews.llvm.org/D4705
2014-07-30auto merge of #15670 : epdtry/rust/fast-archive-builder, r=alexcrichtonbors-20/+33
When rustc produces an rlib, it includes the contents of each static library required by the crate. Currently each static library is added individually, by extracting the library with `ar x` and adding the objects to the rlib using `ar r`. Each `ar r` has significant overhead - it appears to scan through the full contents of the rlib before adding the new files. This patch avoids most of the overhead by adding all library objects (and other rlib components) at once using a single `ar r`. When building `librustc` (on Linux, using GNU ar), this patch gives a 60-80% reduction in linking time, from 90s to 10s one machine I tried and 25s to 8s on another. (Though `librustc` is a bit of a special case - it's a very large crate, so the rlib is large to begin with, and it also relies on a total of 45 static libraries due to the way LLVM is organized.) More reasonable crates such as `libstd` and `libcore` also get a small reduction in linking time (just from adding metadata, bitcode, and object code in one `ar` invocation instead of three), but this is not very noticeable since the time there is small to begin with (around 1s).
2014-07-29rustc: Switch dsymutil status => outputAlex Crichton-1/+1
Sometimes dsymutil writes to stdout/stderr which rust isn't reading, which may cause a deadlock. Closes #16060
2014-07-29speed up static linking by combining `ar` invocationsStuart Pernsteiner-20/+33
2014-07-29Port Rust to DragonFlyBSDMichael Neumann-1/+9
Not included are two required patches: * LLVM: segmented stack support for DragonFly [1] * jemalloc: simple configure patches [1]: http://reviews.llvm.org/D4705
2014-07-21rustc: Append platform exe suffix to output filesAlex Crichton-1/+10
Closes #15828
2014-07-18rustc: Mix extra-filename in temp outputsAlex Crichton-8/+12
When invoking the compiler in parallel, the intermediate output of the object files and bytecode can stomp over one another if two crates with the same name are being compiled. The output file is already being disambiguated with `-C extra-filename`, so this commit alters the naming of the temporary files to also mix in the extra filename to ensure that file names don't clash.
2014-07-18rustc: #[crate_name] and --crate-name must matchAlex Crichton-1/+12
Part of the original discussions around the `--crate-name` flag brought up that mass confusion can arise when the flag specifies a different name than is contained in the crate. The current primary use case of the `--crate-name` flag is through cargo and not requiring a `#[crate_name]` attribute, but if the `#[crate_name]` attribute is specified it will likely go awry when the two names deviate from one another. This commit requires that if both are provided they both match to prevent this confusion.
2014-07-18auto merge of #15725 : aochagavia/rust/vec, r=alexcrichtonbors-1/+1
* Deprecated `to_owned` in favor of `to_vec` * Deprecated `into_owned` in favor of `into_vec` [breaking-change]
2014-07-17Rename functions in the CloneableVector traitAdolfo Ochagavía-1/+1
* Deprecated `to_owned` in favor of `to_vec` * Deprecated `into_owned` in favor of `into_vec` [breaking-change]
2014-07-17auto merge of #15698 : Zoxc/rust/code-model, r=alexcrichtonbors-1/+17
The default code model is usually unsuitable for kernels, so we add an option to specify which model we want. Testing for this would be fragile and very architecture specific and is better left to LLVM.
2014-07-15Support for specifying the code modelJohn Kåre Alsaker-1/+17
The default code model is usually unsuitable for kernels, so we add an option to specify which model we want.
2014-07-15Deprecate `str::from_utf8_lossy`Adolfo Ochagavía-1/+1
Use `String::from_utf8_lossy` instead [breaking-change]
2014-07-15Deprecate `str::from_utf8_owned`Adolfo Ochagavía-4/+2
Use `String::from_utf8` instead [breaking-change]
2014-07-14rustc_llvm: Remove the inner llvm moduleBrian Anderson-58/+59
This makes it much saner for clients to use the library since they don't have to worry about shadowing one llvm with another.
2014-07-14rustc: Move archive to rustc_backBrian Anderson-231/+0
2014-07-14rustc: Move ArchiveRO to rustc_llvmBrian Anderson-56/+1
It is a wrapper around LLVM.
2014-07-14rustc: Invert some archive depsBrian Anderson-34/+85
2014-07-14Extract rpath to rustc_back::rpathBrian Anderson-238/+0
2014-07-14rustc: Invert some rpath dependenciesBrian Anderson-85/+77
2014-07-14Extract librustc_back from librustcBrian Anderson-1003/+97
2014-07-10rustc: Always mark #[crate_name] as usedAlex Crichton-3/+7
It's just an annoying error if you use --crate-name on the command line and you also have a #[crate_name] specified
2014-07-08auto merge of #14832 : alexcrichton/rust/no-rpath, r=brsonbors-2/+2
This commit disables rustc's emission of rpath attributes into dynamic libraries and executables by default. The functionality is still preserved, but it must now be manually enabled via a `-C rpath` flag. This involved a few changes to the local build system: * --disable-rpath is now the default configure option * Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH in order to support building rust with rust already installed. * The compiletest program was taught to correctly pass through the aux dir as a component of LD_LIBRARY_PATH in more situations. The major impact of this change is that neither rustdoc nor rustc will work out-of-the-box in all situations because they are dynamically linked. It must be arranged to ensure that the libraries of a rust installation are part of the LD_LIBRARY_PATH. The default installation paths for all platforms ensure this, but if an installation is in a nonstandard location, then configuration may be necessary. Additionally, for all developers of rustc, it will no longer be possible to run $target/stageN/bin/rustc out-of-the-box. The old behavior can be regained through the `--enable-rpath` option to the configure script. This change brings linux/mac installations in line with windows installations where rpath is not possible. Closes #11747 [breaking-change]
2014-07-08std: Rename the `ToStr` trait to `ToString`, and `to_str` to `to_string`.Richo Healey-3/+3
[breaking-change]
2014-07-05rustc: Default #[crate_name] on input, not outputAlex Crichton-8/+13
2014-07-05rustc: Repurpose the --crate-name CLI flagAlex Crichton-0/+10
In a cargo-driven world the primary location for the name of a crate will be in its manifest, not in the source file itself. The purpose of this flag is to reduce required duplication for new cargo projects. This is a breaking change because the existing --crate-name flag actually printed the crate name. This flag was renamed to --print-crate-name, and to maintain consistence, the --crate-file-name flag was renamed to --print-file-name. To maintain backwards compatibility, the --crate-file-name flag is still recognized, but it is deprecated. [breaking-change]
2014-07-05rustc: Add a flag for specifying dependenciesAlex Crichton-3/+10
This comit implements a new flag, --extern, which is used to specify where a crate is located. The purpose of this flag is to bypass the normal crate loading/matching of the compiler to point it directly at the right file. This flag takes the form `--extern foo=bar` where `foo` is the name of a crate and `bar` is the location at which to find the crate. Multiple `--extern` directives are allowed with the same crate name to specify the rlib/dylib pair for a crate. It is invalid to specify more than one rlib or more than one dylib, and it's required that the crates are valid rust crates. I have also added some extensive documentation to metadata::loader about how crate loading should work. RFC: 0035-remove-crate-id
2014-07-05rustc: Stop putting hashes in filenames by defaultAlex Crichton-13/+1
The compiler will no longer insert a hash or version into a filename by default. Instead, all output is simply based off the crate name being compiled. For example, a crate name of `foo` would produce the following outputs: * bin => foo * rlib => libfoo.rlib * dylib => libfoo.{so,dylib} or foo.dll * staticlib => libfoo.a The old behavior has been moved behind a new codegen flag, `-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and a crate name of `foo`, the following outputs would be generated: * bin => foo (same old behavior) * rlib => libfoobar.rlib * dylib => libfoobar.{so,dylib} or foobar.dll * staticlib => libfoobar.a The makefiles have been altered to pass a hash by default to invocations of `rustc` so all installed rust libraries will have a hash in their filename. This is done because the standard libraries are intended to be installed into privileged directories such as /usr/local. Additionally, it involves very few build system changes! RFC: 0035-remove-crate-id [breaking-change]
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-03 13:39:53 +0000