summaryrefslogtreecommitdiff
path: root/gdb/build-id.h
diff options
context:
space:
mode:
authorAlexandra Hájková <ahajkova@redhat.com>2023-01-24 18:13:38 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-02-01 11:12:35 +0000
commit6647f05df023b63bbe056e9167e9e234172fa2ca (patch)
treeb2dc8955a0af2f7260fb379e1cc4085e1d65ee65 /gdb/build-id.h
parent4788abdec79a937e51ad334b608fa1bd03713112 (diff)
downloadbinutils-gdb-6647f05df023b63bbe056e9167e9e234172fa2ca.tar.gz
gdb: defer warnings when loading separate debug files
Currently, when GDB loads debug information from a separate debug file, there are a couple of warnings that could be produced if things go wrong. In find_separate_debug_file_by_buildid (build-id.c) GDB can give a warning if the separate debug file doesn't include any actual debug information, and in separate_debug_file_exists (symfile.c) we can warn if the CRC checksum in the separate debug file doesn't match the checksum in the original executable. The problem here is that, when looking up debug information, GDB will try several different approaches, lookup by build-id, lookup by debug-link, and then a lookup from debuginfod. GDB can potentially give a warning from an earlier attempt, and then succeed with a later attempt. In the cases I have run into this is primarily a warning about some out of date debug information on my machine, but then GDB finds the correct information using debuginfod. This can be confusing to a user, they will see warnings from GDB when really everything is working just fine. For example: warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \ does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). This diagnostic was printed on Fedora 33 even when the correct debuginfo was downloaded. In this patch I propose that we defer any warnings related to looking up debug information from a separate debug file. If any of the approaches are successful then GDB will not print any of the warnings. As far as the user is concerned, everything "just worked". Only if GDB completely fails to find any suitable debug information will the warnings be printed. The crc_mismatch test compiles two executables: crc_mismatch and crc_mismatch-2 and then strips them of debuginfo creating separate debug files. The test then replaces crc_mismatch-2.debug with crc_mismatch.debug to trigger "CRC mismatch" warning. A local debuginfod server is setup to supply the correct debug file, now when GDB looks up the debug info no warning is given. The build-id-no-debug-warning.exp is similar to the previous test. It triggers the "separate debug info file has no debug info" warning by replacing the build-id based .debug file with the stripped binary and then loading it to GDB. It then also sets up local debuginfod server with the correct debug file to download to make sure no warnings are emitted.
Diffstat (limited to 'gdb/build-id.h')
-rw-r--r--gdb/build-id.h10
1 files changed, 8 insertions, 2 deletions
diff --git a/gdb/build-id.h b/gdb/build-id.h
index 4c3f8e0479a..191720ddf28 100644
--- a/gdb/build-id.h
+++ b/gdb/build-id.h
@@ -49,10 +49,16 @@ extern gdb_bfd_ref_ptr build_id_to_exec_bfd (size_t build_id_len,
/* Find the separate debug file for OBJFILE, by using the build-id
associated with OBJFILE's BFD. If successful, returns the file name for the
- separate debug file, otherwise, return an empty string. */
+ separate debug file, otherwise, return an empty string.
+
+ Any warnings that are generated by the lookup process should be added to
+ WARNINGS_VECTOR, one std::string per warning. If some other mechanism can
+ be used to lookup the debug information then the warning will not be shown,
+ however, if GDB fails to find suitable debug information using any
+ approach, then any warnings will be printed. */
extern std::string find_separate_debug_file_by_buildid
- (struct objfile *objfile);
+ (struct objfile *objfile, std::vector<std::string> *warnings_vector);
/* Return an hex-string representation of BUILD_ID. */