Can't compile with --disable-optimize due to undefined references to core::panicking::panic_old

[TimNN]

Note: to get to this issue, #43411 must be fixed first by applying rust-lang/compiler-builtins#181.

When attempting to build rustc without optimizations, linking serialize fails:

          /home/logic/build-tmp/rust-build/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/serialize-7e8d84274b209168.1.o: In function `alloc::btree::node::{{impl}}::push<alloc::string::String,serialize::json::Json>':
          /home/logic/build-tmp/rust-src/src/liballoc/btree/node.rs:573: undefined reference to `core::panicking::panic_old'
          /home/logic/build-tmp/rust-src/src/liballoc/btree/node.rs:595: undefined reference to `core::panicking::panic_old'
          /home/logic/build-tmp/rust-src/src/liballoc/btree/node.rs:603: undefined reference to `core::panicking::panic_old'
          /home/logic/build-tmp/rust-src/src/liballoc/btree/node.rs:605: undefined reference to `core::panicking::panic_old'
          /home/logic/build-tmp/rust-src/src/liballoc/btree/node.rs:607: undefined reference to `core::panicking::panic_old'
          /home/logic/build-tmp/rust-build/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/serialize-7e8d84274b209168.1.o:/home/logic/build-tmp/rust-src/src/liballoc/btree/node.rs:794: more undefined references to `core::panicking::panic_old' follow
          collect2: error: ld returned 1 exit status


error: aborting due to previous error(s)

error: Could not compile `serialize`.

full log

[TimNN]

The issue appears to be, that various symbols from panic_unwind are marked as internal in libstd.so:

000000000018bc90 t rust_eh_personality
0000000000249580 t _ZN4core9panicking9panic_old17hd5ed84fef9dfdb68E

[TimNN]

So, at least for the core::panicking::panic_old failure I'm wondering if something like this could be happening:

• panic_old is "correctly" marked as not-exported from libstd.so
• libserialize.so monomorphizes a function from libstd.so which calls panic_old
• suddenly libserialize.so depends on a function which was assumed to be internal to libstd.so

If that is indeed the case, I'm wondering why we are not seeing that kind of issue more often?

[TimNN]

Now, I'm really confused: When doing an optimized build, the two missing symbols are exported:

$ nm ./build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libstd-f279a465a88fb38f.so | rg 'eh_person|panic_old'
00000000003491a0 d DW.ref.rust_eh_personality
00000000000b8d00 T rust_eh_personality
00000000000dd2d0 T _ZN4core9panicking9panic_old17h9124249c965722d8E
$ nm ./build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/debug/deps/libstd-1c137a8ce7ad3430.so | rg 'eh_person|panic_old'
0000000000529d90 d DW.ref.rust_eh_personality
000000000018bc80 t rust_eh_personality
0000000000249570 t _ZN4core9panicking9panic_old17hd5ed84fef9dfdb68E

[TimNN]

So the thing that seems to make the difference is that, in the debug case, compiler_builtins has undefined references to rust_eh_personality and panic_old, and is linked last:

If compiler_builtins is not linked last (or not at all), the symbols are public.

[steveklabnik]

Triage: It's been two years. Is this bug still relevant?

[awakecoding]

I'm thinking this issue is related to #44322

[Enselic]

Triage: No one said "yes" to

Is this bug still relevant?

so let's close.