[PATCH] D131224: [llvm-objdump] Find debug information with Build ID/debuginfod.

Wed Sep 28 00:37:50 PDT 2022

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

One nitpick suggestion, otherwise LGTM.

================
Comment at: llvm/test/tools/llvm-objdump/debuginfod.test:56
+RUN: FileCheck %s --check-prefix=BADBINARYERROR --input-file %t.err
+BADBINARYERROR: warning: '{{.*}}': The file was not recognized as a valid object file
+
----------------
I'd recommend using FileCheck's `-D` option to provide the file name explicitly for the warning message (e.g. `FileCheck -DFILE=%t.err ...` then `warning: '[[FILE]]':`

================
Comment at: llvm/test/tools/llvm-objdump/debuginfod.test:9
+# Produce a stripped copy of the input binary.
+RUN: llvm-objcopy --strip-debug %p/Inputs/embedded-source %t/stripped
+
----------------
mysterymath wrote:
> jhenderson wrote:
> > Is there a particular reason to use a canned binary instead of building from assembly with debug information (i.e. I believe `llvm-mc -g`)? If so, could you please include the original source file and instructions on how to compile it to create the canned input.
> The binaries produced by llvm-mc don't include build IDs; these are currently produced by lld. I don't know of a LLVM-only way to readably and reliably produce a build ID section.
> I've added a link to the existing embedded-sources.test, which provides the information used to regenerate this file. I had to run the regeneration command as part of this change to ensure that a build ID was present, since the canned binary predates their generation by default.
You //might// be able to write it as raw binary data as an llvm-mc section, but I suspect that won't work for various reasons, so sounds good. Thanks for the explanation.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131224