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
next prev parent 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