Unreliable BFD caching heuristic

Luis Machado lgustavo@codesourcery.com
Mon Nov 25 17:45:00 GMT 2013


On 11/21/2013 03:58 PM, Pedro Alves wrote:
> On 11/21/2013 05:39 PM, Luis Machado wrote:
>> Do you have any proposals on ways to improve this heuristic?
>
> 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.

Luis



More information about the Gdb mailing list