The compiled output of type `cdylib` became larger.

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?

Reproduce the reported cdylib builds with the provided Cargo.toml, src/lib.rs, c_add.o, and cargo +1.**.0-x86_64-unknown-linux-gnu rustc command. Compare the 1.87 and 1.90 libdownstream_cdylib.so files with nm -D, then trace which compiler or linking change introduces the additional runtime symbols and larger output; done when the cause is identified and the regression is explained.