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

#[inline] prevents symbol from appearing in staticlib output #72463

Closed
jamesmunns opened this issue May 22, 2020 · 5 comments · Fixed by #73034
Closed

#[inline] prevents symbol from appearing in staticlib output #72463

jamesmunns opened this issue May 22, 2020 · 5 comments · Fixed by #73034
Assignees
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

@jamesmunns
Copy link
Member

jamesmunns commented May 22, 2020

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib.

Given this drastically simplified example:

/// lib.rs
#![no_std]

#[no_mangle]
pub extern "C" fn square_plus_one(input: usize) -> usize {
    square(input) + 1
}

#[no_mangle]
#[inline]
pub extern "C" fn square(input: usize) -> usize {
    input * input
}

use core::panic::PanicInfo;

/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {
        // Prevent loop mis-optimization
        continue;
    }
}
# Cargo.toml
[package]
name = "inline-ffi"
version = "0.2.0"
edition = "2018"
description = ""
license = ""
documentation = ""
homepage = ""
repository = ""

[lib]
crate-type = ["staticlib"]

[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"

The square_plus_one function makes it to the static library, but the square function does not:

nm -nSC ./target/release/libinline_ffi.a | rg square
0000000000000000 0000000000000009 T square_plus_one

If I remove the #[inline] attribute, we see both functions in the static lib:

nm -nSC ./target/release/libinline_ffi.a | rg square
0000000000000000 0000000000000008 T square
0000000000000000 0000000000000009 T square_plus_one

The relevant docs don't seem to hint that #[inline] can prevent #[no_mangle]/pub extern "C" items from surviving all the way to the final library, or that they shouldn't be used together.

I would expect any function marked pub extern "C" and/or #[no_mangle] should be present in the final artifact, regardless of #[inline] attributes.

I see this behavior on 1.43.1 stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this.

Thanks!

Edit: Simplified Cargo.toml profile settings, they are not needed to reproduce.

This issue has been assigned to @doctorn via this comment.

@jamesmunns jamesmunns added the C-bug Category: This is a bug. label May 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 May 22, 2020
@almindor
Copy link

Tried with 1.32.0 = same result

@doctorn
Copy link
Contributor

doctorn commented May 23, 2020

I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed

@Aaron1011
Copy link
Member

This appears to have been done deliberately: #36280. Maybe it shouldn't apply to staticlibs.

@jamesmunns
Copy link
Member Author

jamesmunns commented Jun 3, 2020

Expanding on @Aaron1011's note, I would also expect this not to apply to cdylibs as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).

@doctorn
Copy link
Contributor

doctorn commented Jun 5, 2020

I think I'm going to take this on

@rustbot claim

@rustbot rustbot self-assigned this Jun 5, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 11, 2020
…matthewjasper

Export `#[inline]` fns with extern indicators

In ancient history (rust-lang#36280) we stopped `#[inline]` fns being codegened if they weren't used. However,

- rust-lang#72944
- rust-lang#72463

observe that when writing something like

```rust
#![crate_type = "cdylib"]

#[no_mangle]
#[inline]
pub extern "C" fn foo() {
    // ...
}
```

we really _do_ want `foo` to be codegened. This change makes this the case.

Resolves rust-lang#72944, resolves rust-lang#72463 (and maybe some more)
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 16, 2020
…matthewjasper

Export `#[inline]` fns with extern indicators

In ancient history (rust-lang#36280) we stopped `#[inline]` fns being codegened if they weren't used. However,

- rust-lang#72944
- rust-lang#72463

observe that when writing something like

```rust
#![crate_type = "cdylib"]

#[no_mangle]
#[inline]
pub extern "C" fn foo() {
    // ...
}
```

we really _do_ want `foo` to be codegened. This change makes this the case.

Resolves rust-lang#72944, resolves rust-lang#72463 (and maybe some more)
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 18, 2020
…matthewjasper

Export `#[inline]` fns with extern indicators

In ancient history (rust-lang#36280) we stopped `#[inline]` fns being codegened if they weren't used. However,

- rust-lang#72944
- rust-lang#72463

observe that when writing something like

```rust
#![crate_type = "cdylib"]

#[no_mangle]
#[inline]
pub extern "C" fn foo() {
    // ...
}
```

we really _do_ want `foo` to be codegened. This change makes this the case.

Resolves rust-lang#72944, resolves rust-lang#72463 (and maybe some more)
@bors bors closed this as completed in 0e332e9 Jun 19, 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

Successfully merging a pull request may close this issue.

6 participants