Improve addr2line support/behaviour
tcbennun opened this issue · 4 comments
Support Rust demangling
When addr2line demangles Rust symbols, you end up with spaces in a bunch of places, so the current ADDR2LINE_RE doesn't match the output. Example output:
0x400de4eb: core::fmt::num::imp::<impl core::fmt::Display for i32>::fmt at /home/tcb/build/esp-rs/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/src/rust/library/core/src/fmt/num.rs:280
It might be easiest to just match 0x[0-9a-f]+:.* and print the whole thing?
Print inline or out of line?
Currently the behaviour is to replace addresses with addr2line output inline. Maybe it's a personal thing but I prefer the idf_monitor approach of printing the output on the line(s) below the one containing the address(es), in a distinct colour/style. Something like the following, maybe... (using console for colour control):
(Yeah, it's ugly, but at least I'm not gonna mistake it for the real program output.)
Thoughts?
Agree that we should fix the spacing issue with Rust symbol names. I was just looking into the addr2line crate yesterday, which might be a better thing to use, since we won't have to rely on fragile text parsing to get the information we want.
I actually intentionally put the addr2line output mixed in with the output because the other behavior (separate line, what idf_monitor does) actually confused me for the longest time (I couldn't figure out where it was coming from and didn't know that the monitor app was doing it; I thought it was some weird error output generated by the running code itself).
I just worked up this crossterm PR last night, which should fix the polling issues for good, as well as allow us to support console commands on Windows. We could use its facilities to do colorized output for this extra output. I'd be in favor of making the new output more distinct. But since Rust symbol names tend to be a lot longer than C names, I agree it might be a good idea to rethink how that output is presented, as it could get much harder to read if the output is in-line.
Perhaps we can indeed put the output on separate lines, but in addition to adding some color, prefix and indent the line so it's clear that it's "special" and not a part of normal output.
Agreed that it should be much more distinct than idf_monitor's equivalent. Prefix and indent would definitely help. Maybe also a background colour.
Much prefer the addr2line crate also. Better than text parsing, doesn't require having the right toolchain on PATH, and allows things like iterating over inlined functions frame-by-frame from a single address...
Oh, I spent some time trying to use the addr2line crate, and it wasn't as easy as expected. Turns out (if you look at the addr2line example CLI tool they provide) there's a bit more you have to do than just use the addr2line crate's small API. Mostly now I'm having issues because the object and addr2line crates like to borrow the input data in ways that make it hard for me to pass around everything that's needed to make this work.