This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Unreliable BFD caching heuristic
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>
- Cc: Pedro Alves <palves at redhat dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>, Tom Tromey <tromey at redhat dot com>
- Date: Mon, 25 Nov 2013 18:08:05 +0000
- Subject: Re: Unreliable BFD caching heuristic
- Authentication-results: sourceware.org; auth=none
- References: <528E454F dot 6060003 at codesourcery dot com> <528E49B8 dot 8090409 at redhat dot com> <52938CB2 dot 8080700 at codesourcery dot com>
On Mon, 25 Nov 2013, Luis Machado wrote:
> > Compare st_ino/st_dev, and don't share if the system doesn't
> > provide meaningful bfd_stat data?
> >
> > symfile.c:separate_debug_file_exists does this already,
> > and then does a CRC check if all else fails. Not sure
> > whether the CRC part would be a good idea here.
> >
>
> I don't think the inode and device information are portable enough for us to
> use.
>
> The file CRC seems more appropriate in terms of portability, but we need to
> open the bfd, check the CRC and (maybe) close it if we find a cached entry.
> Sounds like a potential performance drawback, but it is more reliable IMO.
>
> We can't rely on the timestamp due to some filesystems having 1 second or 2
> seconds resolution. That doesn't seem enough.
The system clock may also have a 1 second resolution only (although these
are quite rare indeed these days) and a timestamp can be interfered with
(unless we check ctime too, but then some filesystems don't store it).
Calculating a CRC of the whole file may be unacceptably slow with large
executablees and slower targets, and may therefore defeat the very purpose
of BFD caching. If we were going down that path, then may I suggest
revisiting my original proposal to calculate a CRC or some other hash
value instead of raw ELF file/program/section headers (as available) that
we need to access anyway (and if cached in BFD, i.e. previously accessed,
then chances are to have them in the buffer cache already).
Maciej