Dwarf Error: Cannot find DIE at 0x2a09d803 referenced from DIE at 0x2a131f6e from GDB

[jrmuizel]

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 <GOFF=0x29ef2f6e>
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 (30cf806 2017-03-10)

[jrmuizel]

Here's the object that has the bad debug info

[Mark-Simulacrum]

Uploaded the object to GH so it at least don't get lost over time.

gkrust-bcbb9c2502fcc111.0.o.xz.zip

[sbourdeauducq]

Did someone find a solution or workaround to this?

[korken89]

Hi we hit this bug in the stm32l4xx-hal (stm32-rs/stm32l4xx-hal#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 (b8cedc0 2020-03-09) / Linux archbook 5.4.24-1-lts

[ryankurte]

huh, seems broken with the atsamd hal too, did you find anything else about this @korken89 ?

[korken89]

@ryankurte unfortunately not, the issue persists.

[xobs]

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)

[robamu]

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) 

[robamu]

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

[xobs]

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

[philipc]

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.

[jyn514]

Closing as a duplicate of #66118.