[PATCH] D112759: [llvm] [Debuginfo] Add llvm-debuginfod-find tool and end-to-end-tests.

Mon Dec 6 04:55:29 PST 2021

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

In D112759#3172488 <https://reviews.llvm.org/D112759#3172488>, @noajshu wrote:

> Regarding the output behavior, Elfutils `debuginfod-find` prints the path of the fetched/cached artifact file to stdout. By default, `llvm-debuginfod-find` does the same. I've also added a command line flag `llvm-debuginfod-find --dump` which dumps the //contents// of the artifact to stdout instead of its file path.
> If you can only print the path to the cached file, you have to read the stdout and then use that path as the argument to another program (e.g. `cat`). This is easy to do in a full shell using `xargs`, or  a subshell or variable, but inconvenient in LLVM Lit scripts which use a sequence of LLVM commands chained by pipes.
>
> Does this output behavior of `llvm-debuginfod-find` and the `--dump` flag seem reasonable to you? If it's more clear we could change the name to `--print-contents` or something else. Thanks!

Yeah, this isn't easy to do from a lit test. My idea was (since you have a python script anyway) to implement the read-the-filename-and-dump-contents functionality in python. *However*, having the ability for the tool to dump the file contents seems like it could potentially be useful as well, so I have no problem with doing it this way. I have no opinion on the option name.

================
Comment at: llvm/tools/llvm-debuginfod-find/llvm-debuginfod-find.cpp:31
+#include "llvm/Support/Path.h"
+#include "llvm/Support/StringSaver.h"
+#include "llvm/Support/raw_ostream.h"
----------------
Are you sure you're (still) using all of these headers?

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

https://reviews.llvm.org/D112759