diff options
author | Alexandra Hájková <ahajkova@redhat.com> | 2023-01-24 18:13:38 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-02-01 11:12:35 +0000 |
commit | 6647f05df023b63bbe056e9167e9e234172fa2ca (patch) | |
tree | b2dc8955a0af2f7260fb379e1cc4085e1d65ee65 /gdb/build-id.h | |
parent | 4788abdec79a937e51ad334b608fa1bd03713112 (diff) | |
download | gdb-6647f05df023b63bbe056e9167e9e234172fa2ca.zip gdb-6647f05df023b63bbe056e9167e9e234172fa2ca.tar.gz gdb-6647f05df023b63bbe056e9167e9e234172fa2ca.tar.bz2 |
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.h | 10 |
1 files changed, 8 insertions, 2 deletions
diff --git a/gdb/build-id.h b/gdb/build-id.h index 4c3f8e0..191720d 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. */ |