gdb: merge debug symbol file lookup code from coffread & elfread paths
authorAndrew Burgess <aburgess@redhat.com>
Fri, 13 Oct 2023 08:50:33 +0000 (09:50 +0100)
committerAndrew Burgess <aburgess@redhat.com>
Tue, 14 Nov 2023 11:32:02 +0000 (11:32 +0000)
commit27807da584977d7d92822473b35ce94a7d81b21c
tree658b672963474cd32bc14eba02380700cd8872aa
parent7628a997f27af115006c370d58f27d38330814fe
gdb: merge debug symbol file lookup code from coffread & elfread paths

This commit merges the code that looks for and loads the separate
debug symbol files from coffread.c and elfread.c.  The factored out
code is moved into a new objfile::find_and_add_separate_symbol_file()
method.

For the elfread.c path there should be no user visible changes after
this commit.

For the coffread.c path GDB will now attempt to perform a debuginfod
lookup for the missing debug information, assuming that GDB can find a
build-id in the COFF file.

I don't know if COFF files can include a build-id, but I the existing
coffread.c code already includes a call to
find_separate_debug_file_by_build-id, so I know that it is at least OK
for GDB to ask a COFF file for a build-id.  If the COFF file doesn't
include a build-id then the debuginfod lookup code will not trigger
and the new code is harmless.

If the COFF file does include a build-id, then we're going to end up
asking debuginfod for the debug file.  As build-ids should be unique,
this should be harmless, even if debuginfod doesn't contain any
suitable debug data, it just costs us one debuginfod lookup, so I'm
not too worried about this for now.

As with the previous commit, I've done some minimal testing using the
mingw toolchain on a Linux machine, GDB seems to still access the
split debug information just fine.

Approved-By: Tom Tromey <tom@tromey.com>
gdb/coffread.c
gdb/elfread.c
gdb/objfiles.h
gdb/symfile-debug.c