This is an archive of the discontinued LLVM Phabricator instance.

[llvm-strings] Switch command line parsing from llvm::cl to OptTable
ClosedPublic

Authored by MaskRay on Jun 24 2021, 5:36 PM.

Details

Summary

Some behavior changes:

  • -t=d is removed. Use -t d instead.
  • one-dash long options like -all are supported. Use --all instead.
  • --all=0 or --all=false cannot be used. (Note: --all is silently ignored anyway)
  • --help-list is removed. This is a cl:: specific option.

Nobody is likely leveraging any of the above.

Advantages:

  • -t diagnostic gets improved.
  • in the absence of HideUnrelatedOptions, --help will not list unrelated options if linking against libLLVM-13git.so or linker GC is not used.
  • Decrease the probability of cl::opt collision if we do decide to support multiplexing

Note: because the tool is so simple, used more for forensics instead of a building
tool, and its long options are unlikely used in one-dash form, I just drop the
one-dash form in this patch.

Diff Detail

Event Timeline

MaskRay created this revision.Jun 24 2021, 5:36 PM
MaskRay requested review of this revision.Jun 24 2021, 5:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2021, 5:36 PM

one-dash long options like -all are supported

"are no longer"?

Generally seems reasonable to me. However, I am currently assigned to work outside our downstream binutils usage, so don't have time to investigate any ramifications. @gbreynoo, could you please check our downstream internal code bases and see if any of the behaviour changes @MaskRay mentions are going to impact them? If not, then it's okay by me. You'll want an internal ticket to track this change too, since it will require a downstream doc update.

The CommandGuide mentions --help-list, so will need updating as part of this change.

llvm/tools/llvm-strings/Opts.td
19

This should probably list the valid values.

23
llvm/tools/llvm-strings/llvm-strings.cpp
186

If the command guide is correct, I think you can drop this assignment and the corresponding variable (but not the option). The command guide says: Silently ignored. Present for GNU strings compatibility. Also, update the help text accordingly, I'd recommend.

Oh, I think this also loses the --color option, which turns off the error message colouring, if I'm not mistaken. I'm not sure either way how important this is, but thought I'd best flag it up.

I suggest the llvm-strings User Guide also needs updating to reflect these changes, I think only --help-list needs removing.

MaskRay edited the summary of this revision. (Show Details)Jun 25 2021, 1:32 PM
MaskRay edited the summary of this revision. (Show Details)
MaskRay updated this revision to Diff 354594.Jun 25 2021, 1:37 PM

remove --help-list from doc

Oh, I think this also loses the --color option, which turns off the error message colouring, if I'm not mistaken. I'm not sure either way how important this is, but thought I'd best flag it up.

--color is provided by a Support/WithColor.cpp cl::opt which doesn't do anything in llvm-strings.
I guess it cannot be discarded by linker GC due to some references from Support/ .

Oh, I think this also loses the --color option, which turns off the error message colouring, if I'm not mistaken. I'm not sure either way how important this is, but thought I'd best flag it up.

--color is provided by a Support/WithColor.cpp cl::opt which doesn't do anything in llvm-strings.
I guess it cannot be discarded by linker GC due to some references from Support/ .

I dug into the code more, rather than just going off of faulty memory. In other tools at least, --color controls the output colour of error message prefixes, i.e. when printing an error message via WithColor, e.g. "error: some error message" the "error:" prefix is coloured in console output, but can be turned off/on in other contexts etc. llvm-strings however, just prints straight to errs() without going via WithColor. This is actually a bug in llvm-strings in my opinion (we should be consistent with how our messages are printed across the tools). It is however somewhat tangential to this patch, and whilst this bug is present, there's little point in the --color option to my knowledge.

Oh, I think this also loses the --color option, which turns off the error message colouring, if I'm not mistaken. I'm not sure either way how important this is, but thought I'd best flag it up.

--color is provided by a Support/WithColor.cpp cl::opt which doesn't do anything in llvm-strings.
I guess it cannot be discarded by linker GC due to some references from Support/ .

I dug into the code more, rather than just going off of faulty memory. In other tools at least, --color controls the output colour of error message prefixes, i.e. when printing an error message via WithColor, e.g. "error: some error message" the "error:" prefix is coloured in console output, but can be turned off/on in other contexts etc. llvm-strings however, just prints straight to errs() without going via WithColor. This is actually a bug in llvm-strings in my opinion (we should be consistent with how our messages are printed across the tools). It is however somewhat tangential to this patch, and whilst this bug is present, there's little point in the --color option to my knowledge.

If people care about the stderr error messages, they can create a separate patch to fix it....

if (std::error_code EC = Buffer.getError())
  errs() << File << ": " << EC.message() << '\n';

Regarding -all vs --all, if a downstream group needs time for migration, we can add ["-"] temporarily in def NAME: Flag<["--"], name>, HelpText<help1>;
But I prefer not to do that in this patch, as the failing scenario seems unlikely (strings is more for forensics, not for being used as a build tool).

aganea added a subscriber: aganea.Jul 2 2021, 11:27 AM
aganea added inline comments.
llvm/tools/llvm-strings/llvm-strings.cpp
70–71

Same comment as D105330, it would be nice if the globals were part a stack-based state instead.

MaskRay added inline comments.Jul 2 2021, 11:38 AM
llvm/tools/llvm-strings/llvm-strings.cpp
70–71

I think the global options are fine. They are trivially copyable types. The variables are referenced by more than one function so not localizable straightforwardly.

This tool is not used as a library so global states don't matter as long as they don't collide with other tools.

MaskRay updated this revision to Diff 356240.Jul 2 2021, 11:51 AM
MaskRay marked an inline comment as done.

address comments

MaskRay edited the summary of this revision. (Show Details)Jul 2 2021, 11:52 AM
jhenderson accepted this revision.Jul 5 2021, 12:21 AM

Looks reasonable to me, with one remaining suggestion.

llvm/tools/llvm-strings/Opts.td
17

Perhaps "Print the offset within the file, with the specified radix."?

This revision is now accepted and ready to land.Jul 5 2021, 12:21 AM
MaskRay updated this revision to Diff 356535.Jul 5 2021, 10:43 AM
MaskRay marked 3 inline comments as done.

address comments

MaskRay edited the summary of this revision. (Show Details)Jul 5 2021, 10:44 AM
This revision was landed with ongoing or failed builds.Jul 5 2021, 10:46 AM
This revision was automatically updated to reflect the committed changes.