What level of cargo debug info does samply need?

[konstin]

I noticed full debug with cargo can be large, in our case, they are almost 1GB. OTOH, using debug = "line-tables-only" is much smaller, but also shows a slightly different name resolution.

I was wondering if samply has guidance on what options to use that allow profiling and ideally storing profiling binaries for reproducibility, without creating excessively large files?

The builds, with line-tables-only, with full debug and in release mode:

$ du -h target/*/uv
360M    target/profiling2/uv
986M    target/profiling/uv
54M     target/release/uv

---

The two slightly different profiles:

full https://share.firefox.dev/4dAwjBY

line-tables-only https://share.firefox.dev/4bFmgcu

---

From the cargo docs on the different debuginfo options (https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo):

This flag controls the generation of debug information. It takes one of the
following values:

• 0 or none: no debug info at all (the default).
• line-directives-only: line info directives only. For the nvptx* targets this enables profiling. For other use cases, line-tables-only is the better, more compatible choice.
• line-tables-only: line tables only. Generates the minimal amount of debug info for backtraces with filename/line number info, but not anything else, i.e. no variable or function parameter info.
• 1 or limited: debug info without type or variable-level information.
• 2 or full: full debug info.

Note: The [-g flag][option-g-debug] is an alias for -C debuginfo=2.

[mstange]

I wasn't aware of 1 / limited, that sounds interesting!

With line-tables-only, I would have expected the absence of inline information. But if I look at your second profile and switch to the call tree tab, I can see plenty of call nodes with an "inl" badge, indicating that the debug info still contains inlining information. I'm not sure why that is.

The name resolution differences are also surprising to me. They seem more like different mangling schemes.

Samply makes use of inlining info and line tables, but doesn't use type information. So 1 or limited would seem like the appropriate choice.

I'm not sure exactly what you mean by "storing profiling binaries for reproducibility" but you don't need extra profiling binaries if the only difference between the profiling binaries and the distributable binaries is the amount of debug info. Instead, you can build the distributable binaries with the profiling debug info and then strip the debug info before you distribute the binaries, and store the debug info in a separate file. See rust-lang/rust#105991 and the various build scripts in https://github.com/mstange/samply/tree/main/fixtures/other/simple-example for reference.

[konstin]

I'm not sure exactly what you mean by "storing profiling binaries for reproducibility" but you don't need extra profiling binaries if the only difference between the profiling binaries and the distributable binaries is the amount of debug info. Instead, you can build the distributable binaries with the profiling debug info and then strip the debug info before you distribute the binaries, and store the debug info in a separate file. See rust-lang/rust#105991 and the various build scripts in main/fixtures/other/simple-example for reference.

What I'm trying to do is basically an ablation study for optimizations: Knock out different optimizations, then benchmark and profile with different settings and tools, ideally storing them for reproducibility and to amend or change runs without having to redo all builds. When collecting profiling builds, I noticed that each of them is 1GB - i suspect that isn't good for compile times either (we turn of debug info for unoptimized builds cause it makes them much faster, but I haven't checked optimized builds).

[philipc]

The name resolution differences are also surprising to me. They seem more like different mangling schemes.

I think this is because LLVM omits DW_AT_linkage_name for -g1. What I do in addr2line is use the symbol table first for non-inlined functions (gimli-rs/addr2line#332).

I thought -g1 and -gline-tables-only were equivalent and included inline function information, but not sure.

[philipc]

I looked into this some more:

• for clang, -g1 and -gline-tables-only are equivalent and don't include DW_AT_linkage_name
• rustc's -gline-tables-only is equivalent to clang's
• for rustc, -g1 and -glimited are equivalent and do include DW_AT_linkage_name

So I expect the ideal Cargo.toml setting for profiling rust is debug = "limited".