-
-
Notifications
You must be signed in to change notification settings - Fork 56
Closed
Description
Rust by default uses LLD via its own wrapper, so it takes a bit of persuasion to actually use wild.
The easiest way to reproduce it currently is by modifying config.toml
/bootstrap.toml
to:
[rust]
lld = false
I also build LLVM from source by setting download-ci-llvm = false
but that shouldn't matter.
Then run the problematic test:
❯ PATH=~/Projects/wild:$PATH ./x.py t coretests -- "ilog10_u128"
...
Running tests/lib.rs (build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/coretests-ed4ed2eafac4a1eb)
running 1 tests
error: test failed, to rerun pass `-p coretests --test coretests`
Caused by:
process didn't exit successfully: `/home/mateusz/Projects/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/coretests-ed4ed2eafac4a1eb ilog10_u128 --quiet -Z unstable-options --format json` (signal: 11, SIGSEGV: invalid memory reference)
Build completed unsuccessfully in 0:05:00
GDB wasn't very helpful and interleaves the output with hundreds of warning: (Internal error: pc 0x555555742d0c in read in CU, but not in symtab.)
but LLDB is more useful in my case:
❯ LD_LIBRARY_PATH="." lldb -- ./bin ilog10_u128
(lldb) target create "./bin"
Current executable set to '/home/mateusz/rust/1/bin' (x86_64).
(lldb) settings set -- target.run-args "ilog10_u128"
(lldb) breakpoint set --name coretests::num::int_log::ilog10_u128
Breakpoint 1: where = bin`coretests::num::int_log::ilog10_u128::h5743851781febd6f + 27 at int_log.rs:195, address = 0x00000000001ee64b
(lldb) r
Process 1624725 launched: '/home/mateusz/rust/1/bin' (x86_64)
...
Process 1628529 stopped
* thread #2, name = 'num::int_log::i', stop reason = instruction step into
frame #0: 0x00005555556bafec bin.ref-linker`coretests::num::int_log::ilog10_u128::h5743851781febd6f [inlined] core::num::int_log10::u128::h7203bcbacaf2b2be(val=<unavailable>) at int_log10.rs:87:8
84 log += 32;
85 return log + u32(val as u32);
86 }
-> 87 if val >= 10_000_000_000_000_000 {
^
88 val /= 10_000_000_000_000_000;
89 log += 16;
90 }
(lldb) stepi
Process 1628529 stopped
* thread #2, name = 'num::int_log::i', stop reason = instruction step into
frame #0: 0x00007ffff7dcf570 libgcc_s.so.1`__udivti3(n=<unavailable>, d=10000000000000000) at libgcc2.c:1299:1
So, let's check __udivti3
:
❯ readelf -Ws bin | rg __udivti3
159: 0000000000000000 201 FUNC WEAK HIDDEN UND __udivti3
❯ readelf -Ws bin.ref-linker | rg __udivti3
327: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __udivti3
6878: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __udivti3
Yeah, that symbol surely shouldn't be weak nor hidden.
Metadata
Metadata
Assignees
Labels
No labels