Cannot debug with GDB; DWARF data seems corrupted

[sgray004]

With a fresh build of github.com/riscv-rust/rust, I can successfully compile, deploy, and run each riscv-crates/example to a HiFive1 board. However, I cannot debug using GDB. For example, building hello_world, uploading, running openocd, and then running:

make gdb

Connects to openocd correctly, loads the Rust pretty printers successfully, but GDB emits:

Dwarf Error: Cannot find DIE at 0x48d referenced from DIE at 0x693 [in module /home/foo/riscv-crates/target/riscv32imac-unknown-none/debug/examples/hello_world]

Because of this, symbols don't appear to be loaded, breakpoints cannot be set, etc.

Running llvm-dwarfdump -verify against riscv-crates/target/riscv32imac-unknown-none/debug/examples/hello_world seems to show several DIE errors, including an ...invalid DIE reference 0x0000048d... error similar to the one emitted by GDB above.

Any suggestions?

[dvc94ch]

I've seen this before. I haven't gotten round to debug it in detail.

Which commit of rust/llvm are u using? Debugging debug info can be really annoying. A llvm backend only emits CFI info, everything else should be handled by the generic backend that should be the same across platforms. It could be a nightly rustc regression for example. If you want to debug this, then you want to check the various stages to see where the corruption occurs. ie. is the rlib metadata ok is the metadata ok before linking, etc.

[sgray004]

Thanks for the info. I built off your rust-riscv-master branch at commit ab24013.

I had some success eliminating the DWARF errors experimenting with various options around LTO. But I couldn't get to a combination that worked cleanly and wanted to make sure I wasn't missing something simple.

I'll push on this a bit farther. Thanks.

[dvc94ch]

Are you sure it still happens with commit ab24013? Currently works for me... Have you tried xargo clean?

[sgray004]

Yes, I can confirm that git log reports I'm on ab24013. I often run xargo clean to make sure I'm not picking up old builds. To ensure I wasn't accidentally picking up partially old build pieces of the tooling, I built the RISC-V tools and RISC-V Rust fork on a fresh VM from scratch (Ubuntu 16.04.4) and I'm still getting the Dwarf Error within GDB.

[dvc94ch]

fyi got the error again. did you get anywhere with it?

[dvc94ch]

Weirdly it only seems to happen when the binary reaches a certain size (.text > 60000 when running llvm-size).

[dvc94ch]

Worked around it by adding this:
[profile.dev]
opt-level = 3

[dvc94ch]

Ok so it seems like the error occurs when rust expects a function to be inlined but it isn't because the llvm optimization level is set too low.

Fixed most debug info errors by disabling inlining by increasing the inline-threshold in .cargo/config:

  "-C", "inline-threshold=255",

[sgray004]

These workarounds are a definite improvement--GDB is happier.

I'm seeing some issues with the example project where debug symbols aren't present or otherwise seem to be "mismatched." Sometimes I can set a breakpoint on a function symbol, sometimes not. Sometimes the breakpoint hits, sometimes not. Sometimes GDB dumps core. Nothing reproducible yet. I'll spend trying to figure out what's going on.

Do you have a specific GDB debug scenario that is "known good" with these workarounds so that I can validate in my environment to make sure my config is correct?

Much thanks!

[dvc94ch]

The examples that I am using have diverged strongly from what's published. I'll push once the remaining kinks have been ironed out. Splitting hifive into hifive and e310x-hal, full support for the "new io model" and a rtfm riscv port are in the pipeline.

…

On Mar 30, 2018 23:14, "sgray004" ***@***.***> wrote: These workarounds are a definite improvement--GDB is happier. I'm seeing some issues with the example project where debug symbols aren't present or otherwise seem to be "mismatched." Sometimes I can set a breakpoint on a function symbol, sometimes not. Sometimes the breakpoint hits, sometimes not. Sometimes GDB dumps core. Nothing reproducible yet. I'll spend trying to figure out what's going on. Do you have a specific GDB debug scenario that is "known good" with these workarounds so that I can validate in my environment to make sure my config is correct? Much thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAtRrwEDQ8EjfSEIq7CzJ2R9lrTjw3LXks5tjqAwgaJpZM4S76f0> .

[dvc94ch]

So I pushed my changes. They are still a work in progress, but I think they should "mostly work". Due to so many issues with miscompilation and debugging I'm going to focus on other stuff for the time being. Proper atomic support in llvm should allow enabling the rustc testsuite, to help track down the issues.

[sgray004]

Latest changes appear to be working, although as you mentioned, "mostly work" is accurate. I can build, deploy, and set breakpoints on hello_world in GDB and it appears to be working. I do have to boot the HiFive1 using safe mode, for some reason, before I can do uploads.

I'm seeing some oddities around resulting target binary file sizes of 2GB (huge data segments) and sometimes missing .text segments when lto = false. I will continue to investigate.