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

Wed Jul 8 22:39:23 PDT 2020

MaskRay added a comment.

In D83262#2140642 <https://reviews.llvm.org/D83262#2140642>, @MaskRay wrote:

> In D83262#2135629 <https://reviews.llvm.org/D83262#2135629>, @jhenderson wrote:
>
> > I'm personally fine with dropping this if it's not actually useful for you, as I don't have any use-case for it at the current time. Re. --no-inlining, I have a slight preference for not adding it, but I'm also okay with it being added, if you'd find it less confusing. I didn't know about the functionality of `=0` to disable a flag in LLVM tools when I first came to the project myself, so it could be a little confusing. I actually added --no-demangle precisely for that reason.
>
>
> I have a slightly stronger opinion that we should not add it. We could improve help messages for `cl::opt<bool>` to mention the default value.

Given it more thought, perhaps we should switch llvm-symbolizer to llvm-objcopy style `OptTable`. Many `llvm::cl::opt` based tools are not user facing (llc/opt). `llvm::cl::opt` is quick and easy. For user facing utilities (clang/lld/objcopy), OptTable may be more suitable as OptTable can be customized to be similar to the most common GNU-style getopt_long behavior. llvm-readobj/llvm-objdump are a bit special: they don't have defaulted-to-true `llvm::cl::opt<bool>`. If they do, we may face similar conumdrum like `--no-demangle`.

>> 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.
> 
> Do you still have a need for output without source info? We add options if there is a reasonable use case, not that "we add it just to customize a behavior".

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83262