Discrepancy in reported .text size: cargo bloat vs GNU Binuils size

[tnballo]

I noticed cargo bloat report a smaller .text size than GNU binutils size for the same binary (by only a couple KB, but happens to be 10% or so in this case).

Steps to replicate issue documented here, the discrepancy is:

	cargo bloat	cargo size
min_size_no_std	14.7KB	17.0KB
min_size_std	16.4KB	17.8KB

Note cargo size's output is consistent with using the distro-installed size binary from GNU binutils (e.g. size ./target/x86_64-unknown-linux-musl/release/min_size_no_std).

Not sure which tool's output is ground truth, but wanted to bring it to your attention! Thank you for your work on this tool.

[RazrFalcon]

Will have to take a look. cargo-bloat shows .text section size as is. No post-processing. Maybe binutils does something else.

[hudson-ayers]

@tnballo I recommend adding a rust-toolchain file and pegging a particular nightly to each of your examples to simplify the process of replicating your results.

If you pass the -A flag to GNU binutiles size, you will see the actual sizes of each section. Without the -A flag, size uses the Berkeley format, in which "text" is actually the sum of the size of all sections which the size utility guesses to be read only data (source: https://sourceware.org/binutils/docs/binutils/size.html)

[tnballo]

@hudson-ayers - thanks for both suggestions!

I've update the writeup to use a rust-toolchain.toml. AFAIK it supports components but not cargo sub-commands, so I've noted use of cargo-size version 0.3.4 and cargo-bloat version 0.11.0 explicitly (latest availible).

Pegged to nightly-2021-12-04, I still see a slight discrepancy:

	cargo bloat	cargo size
min_size_no_std	13.9KB	14.2KB
min_size_std	16.4KB	16.8KB