[PATCH] D83834: Add test utility 'extract'

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D83834#2171222 <https://reviews.llvm.org/D83834#2171222>, @MaskRay wrote:

> In D83834#2171208 <https://reviews.llvm.org/D83834#2171208>, @dblaikie wrote:
>
> > In D83834#2171199 <https://reviews.llvm.org/D83834#2171199>, @MaskRay wrote:
> >
> > > Use %extract only in `not %extract`
> >
> >
> > So does 'extract' not work the same as all other tools in LLVM? It doesn't get substituted in non-starting locations?
> >
> > That inconsistency seems undesirable/best avoided. The xray collission is problematic, to be sure - might indicate that another name should be used, or perhaps some escaping to disable substitution would be useful (quotation marks seem like a fairly accessible/simple syntax to disable substitution, for instance)
>
>
> llvm/test/lit.cfg.py
>
>   # FIXME: Why do we have both `lli` and `%lli` that do slightly different things?
>   tools.extend([
>       'dsymutil', 'lli', 'lli-child-target', 'llvm-ar', 'llvm-as',
>       'llvm-addr2line', 'llvm-bcanalyzer', 'llvm-config', 'llvm-cov',
>       'llvm-cxxdump', 'llvm-cvtres', 'llvm-diff', 'llvm-dis', 'llvm-dwarfdump',
>       'llvm-exegesis', 'llvm-extract', 'llvm-isel-fuzzer', 'llvm-ifs',
>       'llvm-install-name-tool', 'llvm-jitlink', 'llvm-opt-fuzzer', 'llvm-lib',
>       'llvm-link', 'llvm-lto', 'llvm-lto2', 'llvm-mc', 'llvm-mca',
>       'llvm-modextract', 'llvm-nm', 'llvm-objcopy', 'llvm-objdump',
>       'llvm-pdbutil', 'llvm-profdata', 'llvm-ranlib', 'llvm-rc', 'llvm-readelf',
>       'llvm-readobj', 'llvm-rtdyld', 'llvm-size', 'llvm-split', 'llvm-strings',
>       'llvm-strip', 'llvm-tblgen', 'llvm-undname', 'llvm-c-test', 'llvm-cxxfilt',
>       'llvm-xray', 'yaml2obj', 'obj2yaml', 'yaml-bench', 'verify-uselistorder',
>       'bugpoint', 'llc', 'llvm-symbolizer', 'opt', 'sancov', 'sanstats'])
>
>
> Any tool in this list is special. They can be substituted in any position on a RUN line, either a 'command' position or an 'argument' position. I hope that we can deprecated this behavior.


This looks like a fairly comprehensive list of llvm utilities - seems like "extract" should be included in that list until that deprecation design discussion reaches an agreement. I don't think it's suitable to start down that path before an agreement is reached in an ongoing design discussion.

In D83834#2171217 <https://reviews.llvm.org/D83834#2171217>, @MaskRay wrote:

> In D83834#2171214 <https://reviews.llvm.org/D83834#2171214>, @thakis wrote:
>
> > It's maybe a bit surprising that we have both llvm-extract and extract that are unrelated binaries?
>
>
> Yes. Seems that nobody is unhappy, though http://lists.llvm.org/pipermail/llvm-dev/2020-July/143373.html
>
> > 3. If we add a standalone utility, how shall we name it? (Note that llvm-extract exists, but people can probably distinguish 'extract' from llvm-extract


Fairly small sample of folks in that thread - designing for all the rest of the LLVM developers isn't necessarily "what no one personally objects to".

(though the naming collission with xray extract did get me thinking about naming in general, but also the semantics - would it make sense to call this something like "fragment" (or other synonyms to "split", etc) and have the semantics be more like "write all the file fragments into the specified directory, named after the fragment name" - so you only have to run this tool once, rather than once for every fragment you have?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83834