Closed jrmuizel closed 1 year ago
Uploaded the object to GH so it at least don't get lost over time.
Did someone find a solution or workaround to this?
Hi we hit this bug in the stm32l4xx-hal
(https://github.com/stm32-rs/stm32l4xx-hal/pull/92), when the following code was added: https://github.com/stm32-rs/stm32l4xx-hal/blob/d3358d8de93251409033ac7bef9e3269adb97a0f/src/crc.rs#L138
Is there a known workaround for this?
Tested on: rustc 1.42.0 (b8cedc004 2020-03-09) / Linux archbook 5.4.24-1-lts
huh, seems broken with the atsamd
hal too, did you find anything else about this @korken89 ?
@ryankurte unfortunately not, the issue persists.
I've just run into this on RISC-V as well. It happens as soon as I jump from ASM into Rust code.
(gdb) mon machine Reset
Dwarf Error: Cannot find DIE at 0xccb referenced from DIE at 0xc31b [in module D:\Code\Xous\Core\loader\target\riscv32imac-unknown-none-elf\release\loader]
(gdb) c
Continuing.
Breakpoint 1, fillstack () at src/asm.S:24
24 la t0, abort
(gdb) stepi
0x20501038 24 la t0, abort
(gdb) stepi
25 csrw mtvec, t0
(gdb) stepi
28 j rust_entry
(gdb) stepi
Dwarf Error: Cannot find DIE at 0xccb referenced from DIE at 0xc31b [in module D:\Code\Xous\Core\loader\target\riscv32imac-unknown-none-elf\release\loader]
(gdb)
I get this error when trying to debug a RTT application for a relatively new HAL / PAC combination for a Cortex-M0 based MCU:
Reading symbols from target/thumbv6m-none-eabi/debug/examples/rtt_log...
0x000026d6 in lib::inline::__delay (cyc=<optimized out>,
cyc@entry=<error reading variable: Dwarf Error: Cannot find DIE at 0x18dd referenced from DIE at 0x1280 [in module /home/rmueller/Rust/vorago-rs-workspace/target/thumbv6m-none-eabi/debug/examples/rtt_log]>) at asm/inline.rs:60
60 asm/inline.rs: No such file or directory.
Resetting target
jlink.gdb:6: Error in sourced command file:
Dwarf Error: Cannot find DIE at 0x18dd referenced from DIE at 0x1280 [in module /home/rmueller/Rust/vorago-rs-workspace/target/thumbv6m-none-eabi/debug/examples/rtt_log]
(gdb)
The error might be related to Link-Time-Optimization.
If you have lines like these in your Cargo.toml
:
[profile.dev]
lto = true
debug = true
[profile.release]
lto = true
debug = true
opt-level = 's'
You can try disabling LTO
In my case, the issue was missing a symbol. Namely, _start()
. I have no libc, which as a result caused it to jump to a random offset. For some reason the linker never threw an error.
This is why we create our own _start()
function in our fork of libstd: https://github.com/betrusted-io/rust/blob/1.56.1-xous/library/std/src/sys/xous/common.rs#L15-L18
This issue appears to be the same as #66118, which occurs when LTO is enabled.
In my case, the issue was missing a symbol. Namely, _start().
I wouldn't expect a missing symbol to cause invalid DWARF. It might be that adding the symbol just changes the DWARF enough to hide the problem.
Closing as a duplicate of https://github.com/rust-lang/rust/issues/66118.
I get this error debugging Firefox in GDB.
The relevant portion of a dwarfdump on libxul.so is:
< 6><0x000fc2da GOFF=0x2a131f5e> DW_TAG_subprogram DW_AT_linkage_name _ZN3std11collections4hash3map8{{impl}}8capacityE DW_AT_name capacity DW_AT_decl_file 0x00000012 /home/jrmuizel/src/gecko/gfx/webrender/src/mask_cache.rs DW_AT_decl_line 0x0000003d DW_AT_type
DW_AT_external yes(1)
DW_AT_inline DW_INL_inlined
< 7><0x000fc2ea GOFF=0x2a131f6e> DW_TAG_formal_parameter
DW_AT_name self
DW_AT_decl_file 0x00000012 /home/jrmuizel/src/gecko/gfx/webrender/src/mask_cache.rs
DW_AT_decl_line 0x00000001
DW_AT_type <0x00067b7f GOFF=0x2a09d803>
Searching for 0x2a09d803 in the dwarfdump results seems to match GDB's conclusion that 0x2a09d803 is not there.
I'm using rustc 1.16.0 (30cf806ef 2017-03-10)