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

Panics do not get fully eliminated from shared libraries compiled for Solaris #131765

Open
newpavlov opened this issue Oct 16, 2024 · 1 comment
Labels
A-linkage Area: linking into static, shared libraries and binaries A-panic Area: Panicking machinery needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. O-solaris Operating system: Solaris

Comments

@newpavlov
Copy link
Contributor

Let's use the following crate as an example:

[package]
name = "foo"
version = "0.1.0"
edition = "2021"


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

[profile.release]
panic = "abort"
#![no_std]

#[cfg(not(test))]
#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    extern "C" {
        fn panic_nonexistent() -> !;
    }
    unsafe { panic_nonexistent() }
}

#[no_mangle]
pub extern "C" fn add(a: u32, b: u32) -> u32 {
    a.wrapping_add(b)
}

Compiler successfully eliminates all panics from generated shared library while compiling for a Linux and many other targets (i.e. the panic_nonexistent symbol is not present). But compiling it for x86_64-pc-solaris (e.g. using cross build --release --target=x86_64-pc-solaris) we get a shared library which contains rust_begin_unwind and panic_nonexistent symbols. Here how output of readelf -Ws looks like:

     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000000000e8     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000000140     0 SECTION LOCAL  DEFAULT    2 
     3: 00000000000002d8     0 SECTION LOCAL  DEFAULT    3 
     4: 00000000000003c8     0 SECTION LOCAL  DEFAULT    4 
     5: 0000000000000428     0 SECTION LOCAL  DEFAULT    5 
     6: 0000000000000440     0 SECTION LOCAL  DEFAULT    6 
     7: 0000000000000450     0 SECTION LOCAL  DEFAULT    7 
     8: 0000000000000470     0 SECTION LOCAL  DEFAULT    8 
     9: 0000000000000480     0 SECTION LOCAL  DEFAULT    9 
    10: 0000000000000630     0 SECTION LOCAL  DEFAULT   10 
    11: 0000000000000640     0 SECTION LOCAL  DEFAULT   11 
    12: 0000000000200648     0 SECTION LOCAL  DEFAULT   12 
    13: 0000000000200658     0 SECTION LOCAL  DEFAULT   13 
    14: 0000000000200668     0 SECTION LOCAL  DEFAULT   14 
    15: 00000000002007b8     0 SECTION LOCAL  DEFAULT   15 
    16: 00000000002007d8     0 SECTION LOCAL  DEFAULT   16 
    17: 00000000002007f8     0 SECTION LOCAL  DEFAULT   17 
    18: 0000000000200800     0 SECTION LOCAL  DEFAULT   18 
    19: 0000000000000000     0 SECTION LOCAL  DEFAULT   19 
    20: 0000000000000000     0 SECTION LOCAL  DEFAULT   20 
    21: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crti.s
    22: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    23: 0000000000200648     0 OBJECT  LOCAL  DEFAULT   12 __CTOR_LIST__
    24: 0000000000200658     0 OBJECT  LOCAL  DEFAULT   13 __DTOR_LIST__
    25: 0000000000000640     0 OBJECT  LOCAL  DEFAULT   11 __EH_FRAME_BEGIN__
    26: 0000000000000480     0 FUNC    LOCAL  DEFAULT    9 deregister_tm_clones
    27: 00000000000004b0     0 FUNC    LOCAL  DEFAULT    9 register_tm_clones
    28: 00000000000004f0     0 FUNC    LOCAL  DEFAULT    9 __do_global_dtors_aux
    29: 0000000000200800     1 OBJECT  LOCAL  DEFAULT   18 completed.6467
    30: 0000000000200808     8 OBJECT  LOCAL  DEFAULT   18 dtor_idx.6469
    31: 0000000000000580     0 FUNC    LOCAL  DEFAULT    9 frame_dummy
    32: 0000000000200820    48 OBJECT  LOCAL  DEFAULT   18 object.6479
    33: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    34: 0000000000200650     0 OBJECT  LOCAL  DEFAULT   12 __CTOR_END__
    35: 0000000000000640     0 OBJECT  LOCAL  DEFAULT   11 __FRAME_END__
    36: 00000000000005e0     0 FUNC    LOCAL  DEFAULT    9 __do_global_ctors_aux
    37: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtn.s
    38: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.f48edae78843035f-cgu.0
    39: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS 
    40: 0000000000200800     0 OBJECT  LOCAL  DEFAULT   17 __TMC_END__
    41: 0000000000200660     0 OBJECT  LOCAL  DEFAULT   13 __DTOR_END__
    42: 00000000002007f8     0 OBJECT  LOCAL  DEFAULT   17 __dso_handle
    43: 0000000000200850     0 OBJECT  LOCAL  DEFAULT   18 _END_
    44: 00000000000005c0     6 FUNC    LOCAL  DEFAULT    9 rust_begin_unwind
    45: 0000000000000480     0 OBJECT  LOCAL  DEFAULT    9 _START_
    46: 0000000000200668     0 OBJECT  GLOBAL DEFAULT   14 _DYNAMIC
    47: 0000000000000450     0 OBJECT  GLOBAL DEFAULT    7 _PROCEDURE_LINKAGE_TABLE_
    48: 0000000000000440     0 FUNC    GLOBAL DEFAULT    6 _init
    49: 00000000000005d0     4 FUNC    GLOBAL DEFAULT    9 add
    50: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __deregister_frame_info
    51: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
    52: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable
    53: 0000000000200800     0 NOTYPE  GLOBAL DEFAULT   18 __bss_start
    54: 0000000000000630     0 FUNC    GLOBAL DEFAULT   10 _fini
    55: 0000000000200800     0 NOTYPE  GLOBAL DEFAULT   17 _edata
    56: 00000000002007d8     0 OBJECT  GLOBAL DEFAULT   16 _GLOBAL_OFFSET_TABLE_
    57: 0000000000200850     0 NOTYPE  GLOBAL DEFAULT   18 _end
    58: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND panic_nonexistent
    59: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __register_frame_info
Looking at disassembled library, `rust_begin_unwind` is not used anywhere, so I think it should be eliminated from compiled libraries.
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 16, 2024
@saethlin saethlin added A-linkage Area: linking into static, shared libraries and binaries A-panic Area: Panicking machinery labels Oct 16, 2024
@lolbinarycat lolbinarycat added the O-solaris Operating system: Solaris label Oct 16, 2024
@bjorn3
Copy link
Member

bjorn3 commented Oct 16, 2024

The linker is the one responsible for omitting unused functions. Maybe the Solaris linker is more conservative in it's --gc-sections implementation than other linkers?

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 A-panic Area: Panicking machinery needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. O-solaris Operating system: Solaris
Projects
None yet
Development

No branches or pull requests

5 participants