Re: Unreliable BFD caching heuristic

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