This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/5] Add "target:" filename handling to find_separate_debug_file
- From: Pedro Alves <palves at redhat dot com>
- To: Gary Benson <gbenson at redhat dot com>, gdb-patches at sourceware dot org
- Cc: Cédric Buissart <cedric dot buissart at gmail dot com>
- Date: Wed, 01 Jul 2015 14:35:10 +0100
- Subject: Re: [PATCH 4/5] Add "target:" filename handling to find_separate_debug_file
- Authentication-results: sourceware.org; auth=none
- References: <1434447768-17328-1-git-send-email-gbenson at redhat dot com> <1434447768-17328-5-git-send-email-gbenson at redhat dot com>
On 06/16/2015 10:42 AM, Gary Benson wrote:
> This commit updates find_separate_debug_file to handle filenames
> prefixed with "target:". The same-directory and DEBUG_SUBDIRECTORY
> locations are checked with the prefix if supplied. The debugdir
> location is checked both with and without the prefix if one is
> supplied. This makes GDB able to fetch separate debug files from
> remote targets and from inferiors in containers.
> + /* Try the same location but without TARGET_SYSROOT_PREFIX
> + (i.e. on the local filesystem). */
> + debugfile = build_debug_file_name (no_prefix, debugdir, dir,
> + debuglink, NULL);
Given that we have a CRC to match, shouldn't we try the local
filesystem first, avoiding the (potentially slow) remote fetching
in the case the files on the container/remote are the same of
the host's? (which I think happens often with containers).
And I guess we could skip the "target:" attempt if
target_filesystem_is_local() ?
Fetching (big) debug info files from slow remote targets will
I think lead to the desire for file chunk caching in gdb. But
I think slow debug info beats no debug info.
(Speaking of caching, AFAICS, gdb_bfd_crc/get_file_crc always read in
the whole file and do the crc check locally. It seems really silly
to read in the _whole_ file out of the target in get_file_crc, but
not cache the file's contents for subsequent same-file accesses...
And we could try pushing the CRC calculation to the target side as
well.
But guess with build id validation we'll just not care about this whole
CRC path anymore.)
Thanks,
Pedro Alves