[PATCH] D46407: [tools] Introduce llvm-strip
James Henderson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri May 4 01:28:56 PDT 2018
jhenderson added inline comments.
================
Comment at: tools/llvm-objcopy/CMakeLists.txt:10
tablegen(LLVM Opts.inc -gen-opt-parser-defs)
-add_public_tablegen_target(ObjcopyTableGen)
+add_public_tablegen_target(OptsTableGen)
+
----------------
I'm not really familiar with cmake, but does this name have to be unique? If so, we might want to go back to the old name.
================
Comment at: tools/llvm-objcopy/llvm-objcopy.cpp:487-490
+ if (InputArgs.size() == 0 || InputArgs.hasArg(STRIP_help)) {
+ T.PrintHelp(outs(), "llvm-strip <input> [ <output> ]", "strip tool");
+ exit(0);
+ }
----------------
I think the norm is to exit(1) if the input count is 0, unless help has been specified.
================
Comment at: tools/llvm-objcopy/llvm-objcopy.cpp:498-499
+
+ if (Positional.empty())
+ error("No input file specified");
+
----------------
Test case?
================
Comment at: tools/llvm-objcopy/llvm-objcopy.cpp:519
+ CopyConfig Config;
+ if (sys::path::stem(ToolName).endswith_lower("strip"))
+ Config = ParseStripOptions(makeArrayRef(argv + 1, argc));
----------------
I'm not a massive fan of using the tool's filename to determine the expected behaviour (example reason: if I change the executable from llvm-strip to llvm-strip-backup, when testing two versions of the tool side-by-side, I'd switch to objcopy style behaviour unexpectedly).
How feasible would it be to build two different executables, using the same source code, but a command-line specified define to control this?
Repository:
rL LLVM
https://reviews.llvm.org/D46407
More information about the llvm-commits
mailing list