Re: [PATCH 0/3] bfd cache: tighten match criteria and debug commands.

[Pedro Alves <palves at redhat dot com>]

On 04/13/2015 06:30 PM, Andrew Burgess wrote:
> The consensus in the thread was, I think, that using inode information
> might be the best solution.  I did look at this, but was not sure the
> right place to hook this in; I guess I'd need to add some new bfd
> functions.

The inode/dev info is available right there in the same fstat call
you are hooking into to retrieve the file size:

@@ -369,9 +375,13 @@ gdb_bfd_open (const char *name, const char *target, int fd)
     {
       /* Weird situation here.  */
       search.mtime = 0;
+      search.size = 0;
     }
   else
-    search.mtime = st.st_mtime;
+    {
+      search.mtime = st.st_mtime;
+      search.size = st.st_size;
+    }

That "st" is a "struct stat", which contains:

           struct stat {
               dev_t     st_dev;     /* ID of device containing file */
               ino_t     st_ino;     /* inode number */
               ...
               off_t     st_size;    /* total size, in bytes */

You'd just need to do the exact same you're already doing, but
store st_dev/st_ino instead of st_size?  What am I missing?

Do note that separate_debug_file_exists already does this.

> Given that any solution using inodes would probably be on top of the
> existing match criteria, and that obtaining the file size is pretty
> cheep, I figured there's little harm is having this in place now, and
> adding an inode based criteria later, if wanted.

Although my first reaction was that it does sounds useful for
Windows which leaves st_ino==0, as described in separate_debug_file_exists,
I think that we should instead not share the bfds even if the file
size matches: it's not hard to rebuild the program/library you're debugging
and end up with the same file size but different contents...  A caching/sharing
system that works in most cases, but sometimes fails is not a good system.

Thanks,
Pedro Alves