[PATCH] D83262: [llvm-symbolizer] Add options to disable printing source files & inlining

[Dan Zimmerman via Phabricator via llvm-commits]

danzimm added a comment.

Wow, thanks for the quick and thoughtful response @jhenderson ! This was awesome to wake up to!

> In LLVM tools using the cl::opt interface, like llvm-symbolizer and llvm-addr2line, where you see a cl::opt<bool> (such as --inlining) you should be able to do --inlininng=0 to disable it. I'm not necessarily opposed to --no-inlining too mind you, but wanted to raise that before going further

Whoa, I didn't know that! This is pretty cool! I'll go ahead and pull this change out of this diff. Do you have preference on introducing `--no-inlining`? I think I'll drop it altogether (as opposed to putting it in another diff) in order to try and reduce complexity.

> Most tests for llvm-symbolizer (and llvm-addr2line) are located in llvm/test/tools/llvm-symbolizer (there are a few in other scattered locations - grep for llvm-symbolizer). Any new front-end options like these should be tested there.

Doh! It was right in front of me the whole time! Thanks for pointing that out. Next time (if there is a next time for this diff) I upload changes I'll add some tests!

> Are you specifically interested in symbols at specific addresses, or with a specific type? llvm-nm and llvm-readobj can both be used to dump symbols too. It doesn't feel to me like llvm-symbolizer is the right tool for the job if you want to dump all symbols (or all functions), though I could possibly see an argument if you are limiting it to the symbols with specific addresses. I personally would think it would make more sense to add any necessary options to llvm-nm or possibly llvm-readelf. Adding a few others with binutils knowledge for more visibility and to get their input.

Originally I was interested in mapping a list of addresses to the names of the addresses of functions that appear in the binary from which the addresses came (these addresses are coming from instrumentation, e.g. `-finstrument-function-entry-bare`). After a bit of thought (and trial & error) I think I've concluded I actually do want source file information... it seems symbol names are duplicated across compilation units more often than I had originally expected.

So.... I think for my personal use cases we can go ahead and scrap this diff. I'm also ok with creating the tests and pushing through the `--no-source-file` change (it still probably has some utility in the case when there aren't duplicate symbols). What do you say @jhenderson ? Does scrapping this diff sound ok?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83262/new/

https://reviews.llvm.org/D83262