Skip to content
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

Undefined reference to weak lang items when compilation contains many codegen units #69368

Closed
tmiasko opened this issue Feb 22, 2020 · 0 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@tmiasko
Copy link
Contributor

tmiasko commented Feb 22, 2020

Compiling following under some circumstances result in undefined references to rust_oom:

use std::alloc::{GlobalAlloc, System, Layout};

#[global_allocator]
static GLOBAL: Allocator = Allocator;

struct Allocator;

unsafe impl GlobalAlloc for Allocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 { 
        System.alloc(layout)
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        System.dealloc(ptr, layout)
    }
}

fn main() {}
$ cargo -Zbuild-std test --target x86_64-unknown-linux-gnu
...
error: linking with `cc` failed: exit code: 1
  |
  = note: /usr/bin/ld: /.../target/x86_64-unknown-linux-gnu/debug/deps/liballoc-6e5029e924b1689e.rlib(alloc-6e5029e924b1689e.2h1lbzecyhyarcje.rcgu.o): in function `alloc::alloc::handle_alloc_error':
          /.../.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc/alloc.rs:246: undefined reference to `rust_oom'

This linking issue occurs only under for some codegen partitioning but not the
others. Reproducing it requires controlling the options that influence the
number of codegen units. I can reproduce it with either incremental = true,
or incremental = false combined with codegen-units = 200.

The weak lang items introduce cyclic dependencies between crates. For example,
the alloc crate depends on oom lang item which is defined in std. When linking
the std comes first, and it may so happen that object file that contains
rust_oom definition is not used and omitted (this suggest why large number of
codegen units is necessary to reproduce the issue), and subsequently alloc
crate will fail to link.

The linking code tries to account for cyclic dependencies using
start-group and end-group, but as far as I can see it based on assumption that
weak lang items dependencies are always reversed, which no longer holds true.

@tmiasko tmiasko added the C-bug Category: This is a bug. label Feb 22, 2020
@jonas-schievink jonas-schievink added A-linkage Area: linking into static, shared libraries and binaries T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 22, 2020
tmiasko added a commit to tmiasko/rust that referenced this issue Feb 29, 2020
Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:

* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.

This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.

The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.

Verified using test case from rust-lang#69368.
bors added a commit that referenced this issue Mar 3, 2020
Improve linking of crates with circular dependencies

Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:

* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.

This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.

The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.

Verified using test case from #69368.
bors added a commit that referenced this issue Mar 3, 2020
Improve linking of crates with circular dependencies

Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:

* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.

This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.

The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.

Verified using test case from #69368.
@tmiasko tmiasko closed this as completed Mar 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants