Don't crash on missing addresses - just print them and go on

[jsgf]

This allows stack-sizes to work on binaries where previously it was crashing.

[japaric]

Sorry for taking so long to get to this PR.

This crate is used as a library so we shouldn't print from functions that are called from any of the public API.

Did you run stack-sizes on a stripped binary (e.g. strip -s $binary)? That would explain why the tool panicked: a stripped binary has no symbol table that maps addresses to symbols thus the addresses in the .stack_sizes section produced by the Rust compiler (via -Z emit-stack-sizes) can't be mapped to any meaningful symbol name by the tool.

If you are using the tool on a binary that has not been stripped then I would like to replicate the results myself so I can better understand why a symbol would appear in the .stack_sizes section but not in the .symtab. Since you mentioned linking C++ code it could the case that the C++ object (.o) files were stripped before linking; though I don't know if a linker can work with stripped object files.

[jsgf]

I don't remember the full context, but I'm pretty sure I was running it on freshly compiled binaries with full symbol and debug info present.

[SoftwareApe]

I'm also getting the same error on some, but not all of my C++ executables, so I'm quite keen on having something of the sort merged.

However I understand why printing from a library is unwanted, but could we instead use None here, indicating that the stack wasn't found? Then the caller of the library could deal with this problem. Otherwise we could use std::result to propagate what was the exact issue we encountered.