Closed tgross35 closed 1 month ago
For reference - I compiled for the target (cargo rustc --target arm-linux-androideabi --release -- -C codegen-units=1
) and listed the symbols (nm -gC
) here. Excludes namespaced symbols.
Looks like most of the __aeabi_*
symbols have always been weak (with some exceptions) as well as math symbols, Nothing too surprising.
Building one of the failing tests tests/ui/process/multi-panic.rs
for that target gives these undefined symbols:
U core::fmt::builders::DebugList::finish
U core::fmt::Formatter::debug_list
U core::fmt::Formatter::debug_tuple_field1_finish
U core::fmt::Formatter::debug_tuple_field2_finish
U core::fmt::Formatter::pad
U core::fmt::Formatter::write_str
U core::num::<impl core::str::traits::FromStr for usize>::from_str
U core::slice::index::slice_index_order_fail
U core::slice::index::slice_end_index_len_fail
U core::slice::index::slice_start_index_len_fail
U core::slice::memchr::memchr_aligned
U core::option::unwrap_failed
U core::result::unwrap_failed
U core::panicking::panic_const::panic_const_div_by_zero
U core::panicking::panic_nounwind
U core::panicking::panic_in_cleanup
U core::panicking::panic_bounds_check
U core::panicking::assert_failed_inner
U core::panicking::panic_cannot_unwind
U core::panicking::panic
U core::panicking::panic_fmt
U <std::io::error::Error as core::fmt::Debug>::fmt
U alloc::ffi::c_str::CString::_from_vec_unchecked
U alloc::alloc::handle_alloc_error
U alloc::string::String::from_utf8_lossy
U alloc::raw_vec::handle_error
U <std::sys::pal::unix::stdio::Stderr as std::io::Write>::write
U <std::env::Args as core::iter::traits::iterator::Iterator>::next
U <std::env::Args as core::iter::traits::iterator::Iterator>::size_hint
U <alloc::collections::btree::mem::replace::PanicGuard as core::ops::drop::Drop>::drop
U __aeabi_memclr
U __aeabi_memcpy
U __aeabi_memcpy4
U __aeabi_uidiv
U __rust_alloc
U __rust_alloc_zeroed
U __rust_dealloc
U __rust_no_alloc_shim_is_unstable
U __rust_realloc
U __sync_fetch_and_add_4
U __sync_fetch_and_sub_4
U __sync_lock_test_and_set_4
U __sync_synchronize
U __sync_val_compare_and_swap_4
U close
U fcntl
U memcmp
U rust_eh_personality
Complete shot in the dark here but I wonder if the __sync_*
symbols could be the problem, since they used to be strong but became weak. And all the failing tests seem to have something to do with threads / synchronization. And assuming that if any of the core
/std
symbols had problems, they would have shown up elsewhere.
Missing dunder symbols for each:
__sync_val_compare_and_swap_4
exists on all but terse
, maybe something to check. Disassembly of our version:
Disassembly of section .text._ZN17compiler_builtins9arm_linux29__sync_val_compare_and_swap_417h38f45028923f7fb2E:
00000000 <_ZN17compiler_builtins9arm_linux29__sync_val_compare_and_swap_417h38f45028923f7fb2E>:
0: e92d48f0 push {r4, r5, r6, r7, fp, lr}
4: e59f7034 ldr r7, [pc, #52] @ 40 <_ZN17compiler_builtins9arm_linux29__sync_val_compare_and_swap_417h38f45028923f7fb2E+0x40>
8: e1a05002 mov r5, r2
c: e1a04001 mov r4, r1
10: e1a06000 mov r6, r0
14: e5960000 ldr r0, [r6]
18: e1500004 cmp r0, r4
1c: 1a000006 bne 3c <_ZN17compiler_builtins9arm_linux29__sync_val_compare_and_swap_417h38f45028923f7fb2E+0x3c>
20: e1a00004 mov r0, r4
24: e1a01005 mov r1, r5
28: e1a02006 mov r2, r6
2c: e12fff37 blx r7
30: e3500000 cmp r0, #0
34: 1afffff6 bne 14 <_ZN17compiler_builtins9arm_linux29__sync_val_compare_and_swap_417h38f45028923f7fb2E+0x14>
38: e1a00004 mov r0, r4
3c: e8bd88f0 pop {r4, r5, r6, r7, fp, pc}
40: ffff0fc0 .word 0xffff0fc
Making the __sync_*
symbols strong again fixed this. https://github.com/rust-lang/rust/pull/127561#issuecomment-2235545023
I just realized that another thing changed by https://github.com/rust-lang/compiler-builtins/pull/598, probably inadvertently, is that extern "C"
was dropped. See this part of the diff, $abi
is missing https://github.com/rust-lang/compiler-builtins/pull/598/files#diff-315c02cd05738da173861537577d159833f70f79cfda8cd7cf1a0d7a28ace31bR457-R465.
It seems unlikely but if (1) the system __sync_*
symbols are weak or do not exist, and (2) Rust is using its own ABI, then this could be problematic.
I'm going to do another try run with only this fix just to get a better answer here.
Edit: try https://github.com/rust-lang/rust/pull/127561#issuecomment-2235969765
Looks like maybe it's only the ABI and not weak/strong, see https://github.com/rust-lang/compiler-builtins/pull/642#issuecomment-2236134390
With the ABI fix at e7fd5be54ae5b636d16de041e6700c80624131bf that adds extern "C"
back
Disassembly of section .text._ZN17compiler_builtins9arm_linux29__sync_val_compare_and_swap_417hfe807ac00790ab96E:
00000000 <__sync_val_compare_and_swap_4>:
0: e92d48f0 push {r4, r5, r6, r7, r11, lr}
4: e59f7034 ldr r7, [pc, #52] @ 0x40 <$d.720>
8: e1a05002 mov r5, r2
c: e1a04001 mov r4, r1
10: e1a06000 mov r6, r0
14: e5960000 ldr r0, [r6]
18: e1500004 cmp r0, r4
1c: 1a000006 bne 0x3c <__sync_val_compare_and_swap_4+0x3c> @ imm = #24
20: e1a00004 mov r0, r4
24: e1a01005 mov r1, r5
28: e1a02006 mov r2, r6
2c: e12fff37 blx r7
30: e3500000 cmp r0, #0
34: 1afffff6 bne 0x14 <__sync_val_compare_and_swap_4+0x14> @ imm = #-40
38: e1a00004 mov r0, r4
3c: e8bd88f0 pop {r4, r5, r6, r7, r11, pc}
00000040 <$d.720>:
40: c0 0f ff ff .word 0xffff0fc0
Identical asm except for which registers get pushed or popped. Got you!
In https://github.com/rust-lang/rust/pull/125016#issuecomment-2192794308, android tests are timing out attempting to update CB to 0.1.113. I'm just making this issue for a place to track the debugging effort.
https://github.com/rust-lang/compiler-builtins/pull/598 seems to have caused this; I tested reverting it and the job passed https://github.com/rust-lang/rust/pull/127561#issuecomment-2220041060. Also reverted VisionOS to avoid conflicts, but that should be unrelated.
@maurer tested locally and was able to identify these tests as failing: