This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/3] bfd cache: tighten match criteria and debug commands.
- From: Pedro Alves <palves at redhat dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>, gdb-patches at sourceware dot org
- Date: Mon, 13 Apr 2015 22:17:34 +0100
- Subject: Re: [PATCH 0/3] bfd cache: tighten match criteria and debug commands.
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1428941320 dot git dot andrew dot burgess at embecosm 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