The compiled output of type `cdylib` became larger.

[cezarbbb]

I wrote a small test as follow.
First, I wrote an upstream C static library and compiled it into an object file.

int c_add(int a, int b) {
    return a + b;
}

int c_sub(int a, int b) {
    return a - b;
}

Then I created a cdylib project downstream.
Cargo.toml

[package]
name = "downstream-cdylib"
version = "0.1.0"
edition = "2021"

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

src/lib.rs

extern "C" {
    fn c_add(a: i32, b: i32) -> i32;
}

#[no_mangle]
pub extern "C" fn downstream_add(a: i32, b: i32) -> i32 {
    unsafe { c_add(a, b) }
}

When I compiled using 1.85.0-x86_64-unknown-linux-gnu, the size of libdownstream_cdylib.so was 17KB; when I compiled using 1.87.0-x86_64-unknown-linux-gnu, the size of libdownstream_cdylib.so was still 17KB; however, when I compiled using 1.90.0-x86_64-unknown-linux-gnu, the size of libdownstream_cdylib.so became 396KB.

Compilation command for above all was cargo +1.**.0-x86_64-unknown-linux-gnu rustc --release -- -C link-arg=c_add.o.

Specifically, in 1.87, run nm -D target/release/libdownstream_cdylib.so, we can see:

                 w __cxa_finalize@GLIBC_2.2.5
0000000000001100 T downstream_add
                 w __gmon_start__
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable

However, in 1.90, we can see:

                 U abort@GLIBC_2.2.5
                 U bcmp@GLIBC_2.2.5
                 U calloc@GLIBC_2.2.5
                 U close@GLIBC_2.2.5
                 w __cxa_finalize@GLIBC_2.2.5
                 w __cxa_thread_atexit_impl@GLIBC_2.18
                 U dl_iterate_phdr@GLIBC_2.2.5
00000000000128a0 T downstream_add
                 U __errno_location@GLIBC_2.2.5
                 U free@GLIBC_2.2.5
                 U fstat64@GLIBC_2.33
                 U getcwd@GLIBC_2.2.5
                 U getenv@GLIBC_2.2.5
                 w __gmon_start__
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U lseek64@GLIBC_2.2.5
                 U malloc@GLIBC_2.2.5
                 U memcpy@GLIBC_2.14
                 U memmove@GLIBC_2.2.5
                 U memset@GLIBC_2.2.5
                 U mmap64@GLIBC_2.2.5
                 U munmap@GLIBC_2.2.5
                 U open64@GLIBC_2.2.5
                 U posix_memalign@GLIBC_2.2.5
                 U pthread_key_create@GLIBC_2.34
                 U pthread_key_delete@GLIBC_2.34
                 U pthread_setspecific@GLIBC_2.34
                 U read@GLIBC_2.2.5
                 U readlink@GLIBC_2.2.5
                 U realloc@GLIBC_2.2.5
                 U realpath@GLIBC_2.3
                 U stat64@GLIBC_2.33
                 w statx@GLIBC_2.28
                 U strlen@GLIBC_2.2.5
                 U syscall@GLIBC_2.2.5
                 U __tls_get_addr@GLIBC_2.3
                 U _Unwind_Backtrace@GCC_3.3
                 U _Unwind_GetDataRelBase@GCC_3.0
                 U _Unwind_GetIP@GCC_3.0
                 U _Unwind_GetIPInfo@GCC_4.2.0
                 U _Unwind_GetLanguageSpecificData@GCC_3.0
                 U _Unwind_GetRegionStart@GCC_3.0
                 U _Unwind_GetTextRelBase@GCC_3.0
                 U _Unwind_RaiseException@GCC_3.0
                 U _Unwind_Resume@GCC_3.0
                 U _Unwind_SetGR@GCC_3.0
                 U _Unwind_SetIP@GCC_3.0
                 U write@GLIBC_2.2.5
                 U writev@GLIBC_2.2.5

I want to know what features were added in the new version that caused this increase in binary size?

[Noratrieb]

The easiest way to answer this is to use cargo-bisect-rustc.

[usamoi]

This appears to be caused by lld, so it can be reproduced on all nightly toolchains. lld links libstd, while bfd does not. Using -Clinker-features=-lld can get the binary size seen in Rust 1.89.

[Fulgen301]

That's a rather artificial case though - if you're making a library that doesn't need std, you can make it #![no_std], and if you need std, it'll always get linked in anyway.

[bjorn3]

This is probably caused by the fact that lld removes unused entries from .eh_frame after applying --gc-sections. .eh_frame generally contains a reference to rust_eh_personality, so this function is always kept even if after removing unused entries from .eh_frame removes the rust_eh_personality reference. rust_eh_personality can probably panic and as such pulls in the entire panic machinery. If any code you wrote in your cdylib could panic, then without lld you would have goten a 400kb binary too.

[Noratrieb]

looks like llvm/llvm-project#165097 then

[Noratrieb]

But this would probably mostly be fixed by #148105, which I need to get to again in the future. I say mostly because it would make the size increase really small but not removed entirely.