It would be beneficial to be able to query a debuginfod-server for its metadata matching certain conditions. This would allow for operations like seeing what executable files are available without attempting to download them or seeing which files are larger than a certain size, which could be used to prefetch+cache large required files, before the user needs them. The proposed format is as follows: debuginfod-find [OPTION]... metadata CONDITION QUERYFMT Query all of the metadata matching the given CONDITION and return it as described by QUERYFMT The supported debuginfod-fields are: BUILDID, FILENAME, MODIFIED_TIME, SIZE, TYPE, SOURCE_TYPE, SOURCE and should be referenced using {...}, noting that field names are case insensitive. CONDITION is a boolean expression composed of debuginfod-fields, constants (strings and integers) and the: `( ) = != < > <= >= && ||` operators, following the standard conditional precedence order QUERYFMT is a modified version of the standard printf(3) formatting. The format is made up of static strings (which may include standard C character escapes for new‐ lines, tabs, and other special characters (not including \0)) and printf(3) type formatters. In place of the type specifier in the format string, use the debuginfod-field you wish to query. For example: debuginfod-find metadata "{FILENAME}=/usr/bin/grep && {TYPE}=E" "{FILENAME}({BUILDID})\t{SOURCE_TYPE}\n" Will query all executables with the name /usr/bin/grep and might return the following /usr/bin/grep(90e7d8894b94f47ad17722ff8658f833f329b035) R /usr/bin/grep(e81e4e6e322030178260ae4f6055f781cd4997e1) F debuginfod-find metadata "{FILENAME}=/bin/bash" "{FILENAME}-{TYPE}\n" Might return /bin/bash-E /bin/bash-S /bin/bash-D
I think it's very similar to PR 28284.
Created attachment 14289 [details] Submit A Patch for 29472 Here is patch which is simpler than the above proposal. It allows for querying by source path and will return a JSON array of metadata (where the metadata for each file is its own JSON object). The patch was tested using the elfutils try-buildbots on branch users/rgoldber/try-metadata_query There is a need for this patch as currently, even with work like PR 28284, a user is unable to check what files are accessible with debuginfod, they can only at most try and query by buildid and see if they can get a result. This feature will be used in systemtap PR 27410
Created attachment 14306 [details] Submit A Patch for 29472, bug fix Minor bug fix to be applied to the previous patch
Created attachment 14310 [details] Submit A Patch for 29472, revised I've revised the previous patch to include the suggestions from elfutils-devel [debuginfod metadata patch review]
Followup patch: https://patchwork.sourceware.org/project/elfutils/patch/20221101142306.GL16441@redhat.com/
merged as: commit d47d93b1049ecfad2f9bb9db30dc630c3d6131ca (HEAD -> master, origin/main) gpg: Signature made Mon 03 Jun 2024 11:22:56 AM EDT gpg: using RSA key 4DD136490411C0A42B28844F258B6EFA0F209D24 gpg: Good signature from "Frank Ch. Eigler <fche@elastic.org>" [ultimate] Author: Frank Ch. Eigler <fche@redhat.com> Date: Mon Oct 31 17:40:01 2022 -0400 PR29472: debuginfod: add metadata query webapi, C api, client This patch extends the debuginfod API with a "metadata query" operation. It allows clients to request an enumeration of file names known to debuginfod servers, returning a JSON response including the matching buildids. This lets clients later download debuginfo for a range of versions of the same named binaries, in case they need to to prospective work (like systemtap-based live-patching). It also lets server operators implement prefetch triggering operations for popular but slow debuginfo slivers like kernel vdso.debug files on fedora. Implementation requires a modern enough json-c library, namely 0.11, which dates from 2014. Without that, debuginfod client/server bits will refuse to build. % debuginfod-find metadata file /bin/ls % debuginfod-find metadata glob "/usr/local/bin/c*" Refactored several functions in debuginfod-client.c, because the metadata search logic is different for multiple servers (merge all responses instead of first responder wins). Documentation and testing are included. Signed-off-by: Ryan Goldberg <rgoldber@redhat.com> Signed-off-by: Frank Ch. Eigler <fche@redhat.com>