Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 01/10] change gdb to refcount bfd everywhere
Date: Thu, 19 Jul 2012 20:58:00 -0000	[thread overview]
Message-ID: <877gtzxyck.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20120719141750.GB23801@host2.jankratochvil.net> (Jan	Kratochvil's message of "Thu, 19 Jul 2012 16:17:50 +0200")

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> The comments are present in both and neither is a reference, they
Jan> are already out of sync.

I don't really follow, but I also don't mind changing the comments --
they ought to be clear for everybody, not just me.  How about this?

/* Increment the reference count of ABFD.  It is fine for ABFD to be
   NULL; in this case the function does nothing.  */

void gdb_bfd_ref (struct bfd *abfd);

/* Decrement the reference count of ABFD.  If this is the last
   reference, ABFD will be freed.  If ABFD is NULL, this function does
   nothing.  */

void gdb_bfd_unref (struct bfd *abfd);


Jan> I personally disagree about the returned value from gdb_bfd_ref
Jan> being useful, it makes the code more magic IMO (plus it is not much
Jan> compatible with the narrow GNU Coding Standard code formatting).

I made this change.  I'll test the patch and send it tomorrow.

Then I went a bit further and wrote a follow-up patch that wraps the
various BFD-opening functions with gdb equivalents.  These initialize
the refcount and stash the filename.

E.g.:

    /* A wrapper for bfd_fopen that initializes the gdb-specific reference
       count and calls gdb_bfd_stash_filename.  */

    bfd *gdb_bfd_fopen (const char *, const char *, const char *, int);

I'll send this patch separately tomorrow.  I'm curious to know what you
think.  I find it cleans up the code quite a bit, I wish I'd done this
from the beginning.

>> @@ -193,9 +194,9 @@ allocate_objfile (bfd *abfd, int flags)
[...]
>> -  objfile->obfd = gdb_bfd_ref (abfd);
>> +  objfile->obfd = abfd;

Jan> Caller could gdb_bfd_unref its reference but YMMV.

I will look into this tomorrow.

Jan> This all pain would not exist with C++.

Yeah, well...

>> @@ -2519,14 +2512,10 @@ reread_symbols (void)
>> to close the descriptor but BFD lacks a way of closing the
>> BFD without closing the descriptor.  */
>> obfd_filename = bfd_get_filename (objfile->obfd);
>> -	  if (!bfd_close (objfile->obfd))
>> -	    error (_("Can't close BFD for %s: %s"), objfile->name,
>> -		   bfd_errmsg (bfd_get_error ()));
>> +	  gdb_bfd_unref (objfile->obfd);
>> objfile-> obfd = bfd_open_maybe_remote (obfd_filename);
>> if (objfile->obfd == NULL)
>> error (_("Can't open %s to read symbols."), objfile->name);
>> -	  else
>> -	    objfile->obfd = gdb_bfd_ref (objfile->obfd);

Jan> Why isn't gdb_bfd_ref missing here?

bfd_open_maybe_remote returns a new reference.

I wonder if I should rename it to gdb_bfd_open_maybe_remote, for
consistency.  What do you think?  I'm inclined to do it.

Tom


  reply	other threads:[~2012-07-19 20:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-18 19:32 Tom Tromey
2012-07-19 14:18 ` Jan Kratochvil
2012-07-19 20:58   ` Tom Tromey [this message]
2012-07-20 16:37     ` Tom Tromey
2012-07-20 18:11       ` Jan Kratochvil
2012-07-20 16:37     ` Tom Tromey
2012-07-23  8:54       ` Jan Kratochvil
2012-07-23  9:06         ` Jan Kratochvil
2012-07-23 15:23           ` Tom Tromey
2012-07-23 15:25             ` Tom Tromey
2012-07-24 13:17             ` Jan Kratochvil
2012-07-24 19:52               ` Tom Tromey
2012-07-24 20:27                 ` Eli Zaretskii
2012-07-25 14:25                   ` Tom Tromey
2012-07-25 14:29                     ` Jan Kratochvil
2012-07-25 14:52                       ` Tom Tromey
2012-07-25 14:55                         ` Jan Kratochvil
2012-07-25 15:44                           ` Tom Tromey
2012-07-25 15:37                     ` Eli Zaretskii
2012-07-25 11:57                 ` Jan Kratochvil
2012-07-23 14:52         ` Tom Tromey
2012-07-23 18:54         ` Tom Tromey
2012-07-23 19:02           ` Jan Kratochvil
2012-07-23 19:08             ` Tom Tromey
2012-07-22 19:00     ` Jan Kratochvil
2012-07-23 14:49       ` Tom Tromey
2012-07-23 15:01         ` Tom Tromey
2012-07-23 15:03         ` Tom Tromey
2012-07-20 16:31   ` Tom Tromey
2012-07-20 18:10     ` Jan Kratochvil

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=877gtzxyck.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /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