Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCH v2 0/3] bfd cache: tighten match criteria and debug commands.
Date: Thu, 13 Aug 2015 12:45:00 -0000	[thread overview]
Message-ID: <cover.1439454669.git.andrew.burgess@embecosm.com> (raw)

This is a revision of a patch set that I posted here:
  https://sourceware.org/ml/gdb-patches/2015-04/msg00471.html

The differences in each patch are as follows:

  1/3

  I hope that I addressed everyones comments.  I added comparison of
  inode and device-id fields as suggested by Pedro.

  Gary pointed out a few places where we fake the stat results,
  however, these are all for specialised targets that I don't think
  will be using the bfd caching anyway, the caching is only used for
  local files, ones that can be targeted with a local 'stat' command.
  
  It was also pointed out that Windows does not set the inode field of
  the stat struture.  Pedro semi-suggested that for such targets
  caching should be disabled, while Eli pointed out Windows has an
  alternative API to get the similar data.

  In the end I did neither of these things for the following reasons:

  - Caching provides a general benefit in the common use case.  The
    problem area is basically an edge case in automatted testing.
    Punishing all users (on Windows) because of such a small edge
    case, and one that has existed for a long time feels harsh.

  - To slightly mitigate the above I have left the check of file size
    in place.  In my experience this is often enough to make the
    problem invisible.

  - I don't have a Windows machine for development or testing, but if
    someone else wanted to make use of the Windows API to supply an
    inode like result, this can be easily filled in within
    gdb_bfd_open.

  2/3
  3/3

  Added documentation to the gdb.texinfo file.  I created a whole new
  section to talk about file caching.  I don't know if I filled in
  enough detail, but hopefully what I've written makes sense and is a
  starting point.  I placed all the command documentation there, even
  the maintenance commands, there is precedent for having maintenance
  commands mixed in with other commands so I hope that that will also
  be acceptable.

Andrew Burgess (3):
  gdb: Improve cache matching criteria for the bfd cache.
  gdb: New maintenance command to disable bfd sharing.
  gdb: Add debug tracing for bfd cache activity.

 gdb/ChangeLog       |  26 ++++++++++++
 gdb/NEWS            |   8 ++++
 gdb/doc/ChangeLog   |  11 +++++
 gdb/doc/gdb.texinfo |  45 +++++++++++++++++---
 gdb/gdb_bfd.c       | 118 +++++++++++++++++++++++++++++++++++++++++++++++++---
 5 files changed, 197 insertions(+), 11 deletions(-)

-- 
2.4.0


             reply	other threads:[~2015-08-13 12:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 12:45 Andrew Burgess [this message]
2015-08-13 12:45 ` [PATCH v2 2/3] gdb: New maintenance command to disable bfd sharing Andrew Burgess
2015-08-13 14:24   ` Eli Zaretskii
2015-08-17 17:34   ` Pedro Alves
2015-08-13 12:45 ` [PATCH v2 3/3] gdb: Add debug tracing for bfd cache activity Andrew Burgess
2015-08-17 17:34   ` Pedro Alves
2015-08-13 12:45 ` [PATCH v2 1/3] gdb: Improve cache matching criteria for the bfd cache Andrew Burgess
2015-08-17 17:34   ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1439454669.git.andrew.burgess@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox