enabling LTO triggers "...location info is incomplete..."

[Crzyrndm]

Updating my project today and get this warning

(HOST) WARN  (BUG) location info is incomplete; it will be omitted from the output

Debug build works fine, release build is printing only the bare messages. After tweaking things, changing the release profile from lto = true to lto = false brings back the location information

Project is using RTIC 1.0 and issue persists with very little code (8.7kB binary), although dependencies are still present (shouldn't matter?)

Using

• defmt 0.3
• defmt-rtt 0.3
• probe-run

probe-run --version
0.3.1 
supported defmt version: 3

• Nightly toolchain (selection of dates tested from mid October to latest). Project doesn't compile on stable due to requiring C-variadics for the full project to build
  • nightly-2021-10-20-x86_64-pc-windows-msvc
  • nightly-2021-11-01-x86_64-pc-windows-msvc
  • nightly-2021-12-01-x86_64-pc-windows-msvc
  • nightly-2021-12-30-x86_64-pc-windows-msvc

[profile.release]
codegen-units = 1
debug = 2
lto = "fat"
opt-level = "s"

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip STM32L476RGTx"

[mattico]

I also have this issue. I'm pretty sure it was working a few months ago.

[Urhengulas]

Thanks for tbe report @Crzyrndm!

Do you (or you @mattico) have a minimal example to reproduce this so we can investigate?

PS: Happy new year! 🎉

[japaric]

I can repro with the app-template and the hello example using 1.57.0. 1.56.0 seems to be unaffected. At first glance, it seems that LTO-enabled rustc/llvm is now merging the DWARF info of static variables that have the same name (+) which is making a single defmt log statement have location information. probe-run's 'this ELF has location info' check is very coarse grained. if all log statements have loc info then you get loc info; otherwise you get zero loc info.

(+) all log statements expand to something like this:

// from
defmt::error!("hello");

// to
{
    #[export_name = "hello plus other metadata"]
    static DEFMT_LOG_STATEMENT: u8 = 0;
    let addr = &DEFMT_LOG_STATEMENT as usize;
    // ..
}

it seems that LTO-enabled rustc/llvm is now merging the DWARF info of static variables that have the same name

if this is the problem then changing the name of the static var to include a unique hash as a suffix should fix this (hopefully). the decoding side should also be updated: https://github.com/knurling-rs/defmt/blob/5ef0ba7979e0eb75f981e512c2dd42b7df88fcdf/decoder/src/elf2table/mod.rs#L362

(no more time today to check the above; will test it tomorrow)

[japaric]

At first glance, it seems that LTO-enabled rustc/llvm is now merging the DWARF info of static variables that have the same name

that was not it (should have tested with more than one log statement :upside_down_face: ).

I'm certain we are hitting this rustc bug: rust-lang/rust#90357 . The effect is that all log statements from libraries will be missing location information (when LTO is used). Only the top level bin crate will have location info so, even within the same package src/bin/hello.rs will have loc info but src/lib.rs will not.

probe-run's 'this ELF has location info' check is very coarse grained.

if we relax this check we should get a bit of location info back but in general the compiler is not emitting the information due to the aforementioned bug. GDB is also affected as mentioned in the bug report.