Re: [PATCH 2/5] gdb: merge debug symbol file lookup code from coffread & elfread paths

[Andrew Burgess <aburgess@redhat.com>]

Jon Turney <jon.turney@dronecode.org.uk> writes:

> On 18/10/2023 11:53, Andrew Burgess wrote:
>> 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
>
> This is at least possible for PE/COFF.
>
> (I wrote the code to add support for this back in 2015, see commit 
> c74f7d1c6c5a968330208757f476c67a4bb66643)

Thanks for the link.  I figured they probably could based on the code,
but I didn't dig too hard as I didn't think it really mattered for this
change.

Thanks,
Andrew

>
>> 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.
>
> But yes, as you say, should be harmless.
>
>> I don't have access to a COFF target right now, so beyond compiling
>> it, the coffread.c changes are completely untested.