.rodata wrong with rust about mold

[rui314]

What is your valgrind version? IIRC, valgrind recently made a change so that they are compatible with mold's output.

[limuy2022]

the version is 3.22.0,the latest version

[limuy2022]

in addition，when i use cranelift backend instead of llvm backend.the mold caused another error:

valgrind: debuginfo reader: possibly corrupted debuginfo file

[rui314]

What is your program? I need to reproduce your issue locally to see what's going on.

[limuy2022]

error.zip
in fact,use any rust program with the config.toml in it can reproduce this error

use the following in config.toml can cause the second error

# [unstable]
# codegen-backend = true
#
# [profile.dev]
# codegen-backend = "cranelift"

[rui314]

It works for me. I ran it on Ubuntu 24.04 on Docker.

$ readelf -p .comment target/debug/rust_real_test

String dump of section '.comment':
  [     0]  GCC: (Ubuntu 13.2.0-23ubuntu4) 13.2.0
  [    26]  mold 2.30.0 (aae3b43092ab5e6ae79613e7fae7539c9402e713; compatible with GNU ld)
  [    76]  rustc version 1.77.2 (25ef9e3d8 2024-04-09)

$ valgrind --leak-check=full target/debug/rust_real_test
==8783== Memcheck, a memory error detector
==8783== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==8783== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==8783== Command: target/debug/rust_real_test
==8783==
Value: "hello"
==8783==
==8783== HEAP SUMMARY:
==8783==     in use at exit: 0 bytes in 0 blocks
==8783==   total heap usage: 11 allocs, 11 frees, 3,181 bytes allocated
==8783==
==8783== All heap blocks were freed -- no leaks are possible
==8783==
==8783== For lists of detected and suppressed errors, rerun with: -s
==8783== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

$ valgrind --version
valgrind-3.22.0

[limuy2022]

I cannot reproduce it in debian 12,either.Please keep this issue on,I am a senior high school student and I cannot try finding the problem until the next week.Thank you

[limuy2022]

I found a way to reproduce this issue.By compiling my toy compiler(sorry,other simple rust program cannot reproduce it), using rust cranelift(without cranelift will work well,but only use cranelift can works well,too.so I cannot determine mold and cranelift which caused this issue) and mold can do it by the following steps.
1.Clone my toy compiler
2.Install cranelift
3.use the following config.toml

[unstable]
codegen-backend = true

[profile.dev]
codegen-backend = "cranelift"
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "link-arg=-fuse-ld=mold", "-Z", "threads=8"]

[target.'cfg(target_os = "linux")']
runner = "valgrind --leak-check=full"

4.run cargo build --all
5.run cargo test --all
6.then you can reproduce it in some of the unittest
Sorry,but I really cannot reproduce it in simple rust program.
Error message:

==947486== Memcheck, a memory error detector
==947486== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==947486== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==947486== Command: /home/limuy/trc/target/debug/deps/libcore-e936353cf2358c7f
==947486== 
==947486== Valgrind: debuginfo reader: ensure_valid failed:
==947486== Valgrind:   during call to ML_(img_strdup)
==947486== Valgrind:   request for range [36949181, +1) exceeds
==947486== Valgrind:   valid image size of 36802224 for image:
==947486== Valgrind:   "/home/limuy/trc/target/debug/deps/libcore-e936353cf2358c7f"
==947486== 
==947486== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==947486== Valgrind: I can't recover.  Giving up.  Sorry.
==947486== 

[limuy2022]

If it also doesn't report this error.Try using the dev branch.In my environment,both of them will report the error

[rui314]

Can you upload your executable file that valgrind reported issue with?

[limuy2022]

oh,ok ok.I forgot it.
wrong_exe.zip

[rui314]

I think the executable is not really broken, but it looks like Valgrind just assumes something different. Please report it to Valgrind.

[limuy2022]

Ok.I will report it to valgrind soon

[rui314]

Was it solved upstream?

[limuy2022]

No,I am still waiting for the response.Should I reopen this issue?

[rui314]

No, but I'd like you to paste the link to the upstream bug here for the sake of tracking purposes.

[paulfloyd]

the version is 3.22.0,the latest version

Not any more. 3.23 has been released. Can you try that?

This sounds very much like bugzi 478837.

[limuy2022]

Almost the same question,however,I tried the valgrind 3.23,this problem still here

[paulfloyd]

Almost the same question,however,I tried the valgrind 3.23,this problem still here

Bah.

https://bugs.kde.org/show_bug.cgi?id=486538

[paulfloyd]

I'm not able to reproduce this on FreeBSD.

Please can you do the following:

1. run objdump -p on your exacutable and post the PT_LOAD segments, which should look something like

    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
         filesz 0x0000000000016580 memsz 0x0000000000016580 flags r--
    LOAD off    0x0000000000016580 vaddr 0x0000000000017580 paddr 0x0000000000017580 align 2**12
         filesz 0x000000000004092c memsz 0x000000000004092c flags r-x
    LOAD off    0x0000000000056eb0 vaddr 0x0000000000058eb0 paddr 0x0000000000058eb0 align 2**12
         filesz 0x0000000000002ef8 memsz 0x0000000000003150 flags rw-
    LOAD off    0x0000000000059da8 vaddr 0x000000000005cda8 paddr 0x000000000005cda8 align 2**12
         filesz 0x0000000000000080 memsz 0x0000000000000160 flags rw-

2. Run objdump -h on your exe and pipe it through a grep for rodata
   e.g.

objdump -h target/debug/rust_real_test | grep rodata
14 .rodata 00005dd4 0000000000010410 DATA
16 .rodata.str1.1 00000001 0000000000016206 DATA
17 .rodata.cst4 0000004c 0000000000016208 DATA
18 .rodata.cst8 00000040 0000000000016258 DATA
19 .rodata.cst16 00000260 00000000000162a0 DATA
20 .rodata.cst32 00000080 0000000000016500 DATA

3. run Valgrind -d -d -d on your exe. The output will be very long. I'm only interested in the but releated to reading your exe's elf segments which should look like this

--6368-- di_notify_mmap-0:
--6368-- di_notify_mmap-1: 0x108000-0x11efff r--
--6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test
--6368-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1
--6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024
--6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128
--6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220
--6368-- di_notify_mmap-6: no dinfo loaded /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test (no rx or no rw mapping)
--6368-- di_notify_mmap-0:
--6368-- di_notify_mmap-1: 0x11f000-0x15ffff r-x
--6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test
--6368-- di_notify_mmap-3: is_rx_map 1, is_rw_map 0, is_ro_map 0
--6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024
--6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128
--6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220
--6368-- di_notify_mmap-6: no dinfo loaded /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test (no rx or no rw mapping)
--6368-- di_notify_mmap-0:
--6368-- di_notify_mmap-1: 0x160000-0x163fff rw-
--6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test
--6368-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0
--6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024
--6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128
--6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220
--6368-- di_notify_mmap-6: no dinfo loaded /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test (no rx or no rw mapping)
--6368-- di_notify_mmap-0:
--6368-- di_notify_mmap-1: 0x164000-0x164fff rw-
--6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test
--6368-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0
--6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024
--6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128
--6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220

4. Post the output of valgrind --version

[paulfloyd]

oh,ok ok.I forgot it. wrong_exe.zip

[paulf@archlinux bug]$ valgrind ./wrong_exe
==23348== Memcheck, a memory error detector
==23348== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==23348== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==23348== Command: ./wrong_exe
==23348==
==23348== Valgrind: debuginfo reader: ensure_valid failed:
==23348== Valgrind: during call to ML_(img_strdup)
==23348== Valgrind: request for range [36949181, +1) exceeds
==23348== Valgrind: valid image size of 36802224 for image:
==23348== Valgrind: "/home/paulf/bug/wrong_exe"
==23348==
==23348== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==23348== Valgrind: I can't recover. Giving up. Sorry.

This is a completely different error to the one that has been fixed that you described initially,

[paulfloyd]

dwarfdump -ka also complains

*** DWARF CHECK: .debug_ranges: Address outside a valid .text range ***

As far as I'm concerned this is not a Valgrind issue. The problem is either with rust or with mold.

I've closed the upstream bug.

[limuy2022]

but this file make valgrind report the same issue on Debian.I cannot determine.

[paulfloyd]

You need to find which tool is responsible for writing incorrect debuginfo. The problem doesn't seem to be in Valgrind.

[rui314]

@paulfloyd I didn't get that error when I run dwarfdump -ka wrong_exe on my machine. Did you run it against the file that @limuy2022 uploaded or something else?

[paulfloyd]

I greatly truncated the output. The .debug_ranges message is there something like 13k times.

On Arch Linux in VirtualBox
Static hostname: archlinux
Icon name: computer-vm
Chassis: vm ����
Machine ID: 67a31487732e497ea5240c91dea76001
Boot ID: 9091880bdacc4d50b3174d22d135f797
Virtualization: oracle
Operating System: Arch Linux
Kernel: Linux 6.8.9-arch1-1
Architecture: x86-64
Hardware Vendor: innotek GmbH
Hardware Model: VirtualBox
Firmware Version: VirtualBox
Firmware Date: Fri 2006-12-01
Firmware Age: 17y 5month 1w 3d

dwarfdump --version
dwarfdump [Apr 5 2024 09:24:43 (libdwarf 0.9.2 dwarfdump 0.9.2)]

[rui314]

@limuy2022 I'm still struggling to reproduce your problem. mold has a nice feature to pack all the input files and command line options into a single tar file so that anyone can run mold with the exact same inputs. Can you add -repro to the linker flag, compile your code and then share the generated tar file? That should make reproducing your issue extremely easy.

[limuy2022]

@paulfloyd I think maybe because you are on archlinux so that you can't reproduce this issue.I can't on archlinux,too.But it can be reproduced on debian(maybe ubuntu)
@rui314 I will try that later

[limuy2022]

I tried add this flag,but there is not any tar file generated.Sorry about letting you waiting for such a long time.

[rui314]

Can't you find it with find . -name '*.tar"?

[limuy2022]

Sorry,I am not familiar with find so I used wrong regex to match files.I have found tar,but it is 58 MB after being compressed.How can I send it to you?

[rui314]

Any way is fine. Let me know if you find it difficult to find a place to upload it.

[limuy2022]

I have sent you an email through the email address in your homepage

[rui314]

Thank you for sharing the file. However, it looks like the tar file was created by an old version of mold. Can you upgrade your mold to the latest version and try to see if the problem still persists? If it still occurs, please share a repro file with the latest version.

[limuy2022]

Error turns into warning,but still about debug info.Do you still want the tar file or just close this issue?

[limuy2022]

==8207==
get_Form_contents_str: 14 (DW_FORM_strp) points outside .debug_str
--8207-- WARNING: Serious error when reading debug info
--8207-- When reading debug info from /home/limuy/trc/target/debug/deps/test_stdlib_ffi-9740968e62e19b56:
--8207-- get_Form_contents_str: index points outside .debug_str

[rui314]

Does that happen if you build mold at git head?

[limuy2022]

yes,it still happens

[rui314]

Please share a repro file.

[limuy2022]

Email has been sent

[rui314]

OK, so the problem is that some of your input file has mergeable .debug_str section while others contain non-mergeable .debug_str section. As a result, your executable has two separate .debug_str section, although there should be only one.

Your files contain the following static libraries. All libraries under home/limuy/trc/target/debug/deps contain non-mergeable .debug_str (which is wrong), while those under home/limuy/.rustup contain mergeable sections (which is correct).

./home/limuy/trc/target/debug/deps/libcolored-99d7760ee2a87a42.rlib
./home/limuy/trc/target/debug/deps/libsame_file-2aa863e69860fa07.rlib
./home/limuy/trc/target/debug/deps/libindexmap-70fe8b9a918e945f.rlib
./home/limuy/trc/target/debug/deps/libtoml_edit-939c69677d3e85d0.rlib
./home/limuy/trc/target/debug/deps/liblibmimalloc_sys-46a33c40f782adc4.rlib
./home/limuy/trc/target/debug/deps/liblinked_hash_map-8c7de17ce525d1d4.rlib
./home/limuy/trc/target/debug/deps/libarc_swap-8874ef19c3ba89e4.rlib
./home/limuy/trc/target/debug/deps/libaho_corasick-9cb51d9f7bbf38b1.rlib
./home/limuy/trc/target/debug/deps/libindexmap-d0735d015adc99c7.rlib
./home/limuy/trc/target/debug/deps/libserde_spanned-cf65f1954994580b.rlib
./home/limuy/trc/target/debug/deps/libdowncast_rs-836ad5b13f742168.rlib
./home/limuy/trc/target/debug/deps/liblazy_static-732ad1d2ef9ee695.rlib
./home/limuy/trc/target/debug/deps/libbitflags-ec26a6de9255ed42.rlib
./home/limuy/trc/target/debug/deps/libequivalent-08b81553d5eb0956.rlib
./home/limuy/trc/target/debug/deps/liblog-adf9be2845496e67.rlib
./home/limuy/trc/target/debug/deps/libcrossbeam_utils-f2dab332f85027e2.rlib
./home/limuy/trc/target/debug/deps/libnormpath-9d1cd4bf6be9d7a8.rlib
./home/limuy/trc/target/debug/deps/libstable_deref_trait-c78f15e1ee40c5fa.rlib
./home/limuy/trc/target/debug/deps/libserde-2ce4cc41a747a0c6.rlib
./home/limuy/trc/target/debug/deps/libitoa-b4e0236a8194c163.rlib
./home/limuy/trc/target/debug/deps/librust_i18n-d0cdf7fb0d429dde.rlib
./home/limuy/trc/target/debug/deps/librust_i18n_support-822df550c3b1d81e.rlib
./home/limuy/trc/target/debug/deps/libhashbrown-ce872fa97be3d02b.rlib
./home/limuy/trc/target/debug/deps/libregex_automata-98404c89e80c1ff8.rlib
./home/limuy/trc/target/debug/deps/libcrossbeam_epoch-1090e3bba006a382.rlib
./home/limuy/trc/target/debug/deps/libsmallvec-f0d45bc59fa7e0a4.rlib
./home/limuy/trc/target/debug/deps/libcrossbeam_deque-99bf8ede6153d53b.rlib
./home/limuy/trc/target/debug/deps/liblibc-d0ef0348edd06aae.rlib
./home/limuy/trc/target/debug/deps/libserde_yaml-481dd270e550f008.rlib
./home/limuy/trc/target/debug/deps/libregex_syntax-95e0a2c0210549c0.rlib
./home/limuy/trc/target/debug/deps/libtriomphe-f6ce1bb53823f16b.rlib
./home/limuy/trc/target/debug/deps/libwalkdir-2d5d6150f1ce44f2.rlib
./home/limuy/trc/target/debug/deps/libwinnow-29d4a277da30f19a.rlib
./home/limuy/trc/target/debug/deps/libonce_cell-7fa823b2c48ebe09.rlib
./home/limuy/trc/target/debug/deps/libserde_json-5eead9fd7158ab1f.rlib
./home/limuy/trc/target/debug/deps/libnum_enum-2278c0f3cfb88512.rlib
./home/limuy/trc/target/debug/deps/libyaml_rust-2be9a2c4097260cf.rlib
./home/limuy/trc/target/debug/deps/libryu-1fc77ec92d4d9e1e.rlib
./home/limuy/trc/target/debug/deps/libglobwalk-8b8b9fae666af58c.rlib
./home/limuy/trc/target/debug/deps/libtoml-b60aedb0b0b1b944.rlib
./home/limuy/trc/target/debug/deps/libhashbrown-ad7cfc50eb1a5e1c.rlib
./home/limuy/trc/target/debug/deps/libcollection_literals-60574546e7342bda.rlib
./home/limuy/trc/target/debug/deps/libmemchr-fbaf65534d83d2ad.rlib
./home/limuy/trc/target/debug/deps/libignore-8aaf5f4a9eb21659.rlib
./home/limuy/trc/target/debug/deps/libmimalloc-339b2304a52d67ce.rlib
./home/limuy/trc/target/debug/deps/libbstr-d9b453c6213a67ae.rlib
./home/limuy/trc/target/debug/deps/libtoml_datetime-ab4fcec8a0899a96.rlib
./home/limuy/trc/target/debug/deps/libglobset-a70b6a43dea6aa0b.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-e8bfe52be756260a.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode_width-d3a0a02e04a22c2e.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-5727477b0a78105a.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-58e3f8995df4edb4.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-f3d3451767410a17.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtest-d7a17561695c9eef.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-f72b956e24d1de70.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-b6892f3c52c68f01.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-210d920812faea91.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-d9ed943652059c0d.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-45288dcc88911a1f.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-314a4689716cb02e.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-c3e1f40644ffc9b8.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-7e555563aa211118.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-16717cdb08dfbef5.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_std-969aad6cb597a6e7.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-632ae0f28c5e55ff.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-2caea079085a58a2.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-e8b7e96e438f08f6.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-ee5b5774583426df.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-fd5d5d2c7e8c041e.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-7b90a2705bcf265b.rlib
./home/limuy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-9ff13545d1688b3c.rlib

You can see them by readelf --sections $(find . -name \*.rlib) | grep -F .debug_str. MS indicates a mergeable section.

So, how did you build your libraries? If it was built with an older version of rust compiler, you may want to try to rebuild them.

[limuy2022]

I am building with the latest nightly rust compiler in general way.Every time before I try reproducing the problem I will clean and rebuild first.

[limuy2022]

So it is a bug of rustc?

[rui314]

Yes

[limuy2022]

I have reported it to rust

[rui314]

Can you share a link to that bug so that we can track progress?

[limuy2022]

link

[limuy2022]

This issue has been fixed by upstream