figure out debug symbols for Rust programs and libraries |
|
Issue description
I compile memd with --release:
cargo build -v --target="${CHOST}" --release
and with these cargo options:
[profile.release]
lto = true
panic = 'abort'
With this setup, the produced memd.debug is about 1MB and gdb does not find the functions in memd/src/main.rs.
If I add
debug = true
to profile.release, the generated memd.debug is about 3MB, and gdb finds those symbols.
Specifically, with debug = true:
$ x86_64-cros-linux-gnu-gdb /build/cyan/usr/bin/memd -s /build/cyan/usr/lib/debug/usr/bin/memd.debug
<skip>
gdb) p memd::run_memory_daemon
$1 = {fn (bool)} 0xc100 <memd::run_memory_daemon>
and without:
(gdb) p memd::run_memory_daemon
No symbol "memd" in current context.
(Interestingly, "nm .../memd.debug" produces a very similar result (same names, but some of the addresses are slightly changed) so that's only part of the story.)
,
Sep 27
There is no way to set profile options globally: https://github.com/rust-lang/cargo/issues/3459 So each crate would have to opt-in.
,
Sep 27
Could this be done by requiring use of our own "ecargo" command?
,
Sep 27
The issue is that as far as I can tell the only way to set this option is in the [profile] section of the Cargo.toml. There is no command line option and no global option.
,
Sep 27
The ecargo command could read the user-provided Cargo.toml and produce a revised version. It might lead to rather unexpected situations though. Maybe the ecargo parser could barf unless the first line contained a comment conveying the notion that "ecargo is allowed to take this file as input and produce a modified version for use in emerge". Then at least the Cargo.toml writer would be aware of the transformation.
,
Sep 28
having ecargo sanity check it to start with is a good idea. we can always iterate on top of that.
,
Oct 2
Soomething like this? https://crrev.com/c/1257587 |
|
►
Sign in to add a comment |
|
Comment 1 by vapier@chromium.org
, Sep 27