From patchwork Mon Apr 13 17:30:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 6186 Received: (qmail 117212 invoked by alias); 13 Apr 2015 17:33:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 117150 invoked by uid 89); 13 Apr 2015 17:33:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-wg0-f53.google.com Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 13 Apr 2015 17:33:11 +0000 Received: by wgsk9 with SMTP id k9so89139153wgs.3 for ; Mon, 13 Apr 2015 10:33:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=tQY7xQt0mdF0/h3mWDdyytHPFLABdsg75fgZxr2Xm5w=; b=A1l947addeZBOQr+yGCznKYr9HCBXr169M9uwMzBGrFxeZIhXk8+ogdDKqQNSfdayf 9/Gb/sKJTacOCyls59tgkWthANJIVhUsHQ7ofbRd6GPKe5S63IqfeAhU6KEefD4qpuGy Q1IURLzlj1tVEH/dI33mKIXdPUnKbs7XI+QZK7b28Ygq8+cV33VQSmch+4cG+9q+fJnm K0xZsLB3QNHMTzmhl7HNK8Y4L+gbFph5NrS4Cml1cJ6jkpUHC1kLw8X8d3S0A578dWWs 1vXl7bOLOHFIuAooa8dexrcTvZaCGvlijCjYB08FVWEk4gDzcTcd8aGqlkkg37KTVgmf eaEw== X-Gm-Message-State: ALoCoQko1vrHplNqMwiKi6R0Rs7zJ5db7XiN82u+OzyP80KJ85f9+0oLHHYHnbaeTsKMzyqInRer X-Received: by 10.194.60.4 with SMTP id d4mr30433545wjr.72.1428946388722; Mon, 13 Apr 2015 10:33:08 -0700 (PDT) Received: from localhost (host86-133-100-115.range86-133.btcentralplus.com. [86.133.100.115]) by mx.google.com with ESMTPSA id l3sm12388791wik.16.2015.04.13.10.33.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 10:33:07 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH 1/3] gdb: Use bfd size as another cache identification criteria. Date: Mon, 13 Apr 2015 18:30:07 +0100 Message-Id: <26efb0498fe33382e2187cbddbe51ba12e6d49d6.1428941320.git.andrew.burgess@embecosm.com> In-Reply-To: References: In-Reply-To: References: X-IsSubscribed: yes Within gdb open bfd objects are reused where possible if an attempt is made to reopen a file that is already being debugged. To spot if the on disc file has changed gdb currently examines the mtime of the file and compares it to the mtime of the open bfd in the cache. A problem exists when the on disc file is being rapidly regenerated, as happens, for example, with automated testing. In some cases the file is generated so quickly that the mtime appears not to change, while the on disc file has changed. This patch extends the bfd cache to also hold the file size of the bfd, something which can be cheaply acquired, gdb can then check the mtime and the file size. This is still not going to catch every on disc change, but does increase the probability that a change will be spotted. OK to apply? Thanks, Andrew gdb/ChangeLog: * gdb_bfd.c (struct gdb_bfd_data): Add size field. (struct gdb_bfd_cache_search): Likewise. (eq_bfd): Compare the size fields. (gdb_bfd_open): Initialise the size field. (gdb_bfd_ref): Likewise. (gdb_bfd_unref): Likewise. --- gdb/ChangeLog | 9 +++++++++ gdb/gdb_bfd.c | 14 +++++++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 8a14194..d79d8e3 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,12 @@ +2015-04-13 Andrew Burgess + + * gdb_bfd.c (struct gdb_bfd_data): Add size field. + (struct gdb_bfd_cache_search): Likewise. + (eq_bfd): Compare the size fields. + (gdb_bfd_open): Initialise the size field. + (gdb_bfd_ref): Likewise. + (gdb_bfd_unref): Likewise. + 2015-04-11 Jan Kratochvil * NEWS (Changes since GDB 7.9): Add removed -xdb. diff --git a/gdb/gdb_bfd.c b/gdb/gdb_bfd.c index 3d5d23f..35c068f 100644 --- a/gdb/gdb_bfd.c +++ b/gdb/gdb_bfd.c @@ -68,6 +68,9 @@ struct gdb_bfd_data /* The mtime of the BFD at the point the cache entry was made. */ time_t mtime; + /* The file size (in bytes) at the point the cache entry was made. */ + off_t size; + /* This is true if we have determined whether this BFD has any sections requiring relocation. */ unsigned int relocation_computed : 1; @@ -111,6 +114,8 @@ struct gdb_bfd_cache_search const char *filename; /* The mtime. */ time_t mtime; + /* The file size (in bytes). */ + off_t size; }; /* A hash function for BFDs. */ @@ -135,6 +140,7 @@ eq_bfd (const void *a, const void *b) struct gdb_bfd_data *gdata = bfd_usrdata (abfd); return (gdata->mtime == s->mtime + && gdata->size == s->size && strcmp (bfd_get_filename (abfd), s->filename) == 0); } @@ -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; + } /* Note that this must compute the same result as hash_bfd. */ hash = htab_hash_string (name); @@ -466,6 +476,7 @@ gdb_bfd_ref (struct bfd *abfd) gdata = bfd_zalloc (abfd, sizeof (struct gdb_bfd_data)); gdata->refc = 1; gdata->mtime = bfd_get_mtime (abfd); + gdata->size = bfd_get_size (abfd); gdata->archive_bfd = NULL; bfd_usrdata (abfd) = gdata; @@ -506,6 +517,7 @@ gdb_bfd_unref (struct bfd *abfd) void **slot; search.mtime = gdata->mtime; + search.size = gdata->size; slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, NO_INSERT);