Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Jan Vrany <jan.vrany@labware.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC 5/9] gdb/python: introduce gdbpy_registry
Date: Thu, 20 Feb 2025 12:28:32 -0700	[thread overview]
Message-ID: <87pljca00v.fsf@tromey.com> (raw)
In-Reply-To: <20250127104435.823519-6-jan.vrany@labware.com> (Jan Vrany's message of "Mon, 27 Jan 2025 10:44:31 +0000")

>>>>> "Jan" == Jan Vrany <jan.vrany@labware.com> writes:

Jan> +#include <unordered_set>
Jan> +#include <unordered_map>

Simon recently imported a hash table so we use gdb::unordered_map and
gdb::unordered_set now.  You can probably just remove the includes and
change the names and things will keep working.

Jan> +   The actuall tracking of "owned" Python objects is handled externally

Small typo, s/actuall/actual/

Jan> +  /* Lookup pre-existing Python object for given VAL.  Return such object
Jan> +     if found, otherwise return NULL.  This method always returns new
Jan> +     reference.  */
Jan> +  template <typename O>
Jan> +  obj_type *lookup (O *owner, val_type *val) const
Jan> +  {

Returning a new reference suggests that perhaps the return type should
be gdbpy_ref<> (or gdbpy_ref<obj_type>).

Jan> +  Storage *get_storage(struct objfile* objf) const
Jan> +  {
Jan> +    return get_storage(objf, m_key_for_objf);

Spaces before "(".  There's a few of these around.

Jan> +  obj_type *lookup (val_type *val) const
Jan> +  {
Jan> +    gdb_assert_not_reached ("Should not be used.");
Jan> +  }

I wonder if these methods can just be deleted?
Like if the registry's 'lookup' template isn't instantiated, perhaps
this function won't ever be called, and so no error generated?

Same question for the assert in the 'remove' method.

Tom

  reply	other threads:[~2025-02-20 19:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27 10:44 [RFC 0/9] Attempt to unify Python object's lifecycle Jan Vrany
2025-01-27 10:44 ` [RFC 1/9] gdb/python: preserve identity for gdb.Symtab objects Jan Vrany
2025-01-27 10:44 ` [RFC 2/9] gdb/python: preserve identity for gdb.Symbol objects Jan Vrany
2025-02-20 19:22   ` Tom Tromey
2025-01-27 10:44 ` [RFC 3/9] gdb/python: do not hold on gdb.Symtab object from gdb.Symtab_and_line Jan Vrany
2025-01-27 10:44 ` [RFC 4/9] gdb/python: preserve identity for gdb.Type objects Jan Vrany
2025-01-27 10:44 ` [RFC 5/9] gdb/python: introduce gdbpy_registry Jan Vrany
2025-02-20 19:28   ` Tom Tromey [this message]
2025-01-27 10:44 ` [RFC 6/9] gdb/python: convert gdb.Symbol to use gdbpy_registry Jan Vrany
2025-01-27 10:44 ` [RFC 7/9] gdb/python: convert gdb.Type " Jan Vrany
2025-01-27 10:44 ` [RFC 8/9] gdb/python: convert gdb.Symtab " Jan Vrany
2025-01-27 10:44 ` [RFC 9/9] gdb/python: convert gdb.Symtab_and_line " Jan Vrany
2025-02-18 11:15 ` [PING] Re: [RFC 0/9] Attempt to unify Python object's lifecycle Jan Vraný
2025-02-19 21:00 ` Simon Marchi
2025-02-20 17:50   ` Jan Vraný
2025-02-20 19:18 ` Tom Tromey

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=87pljca00v.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.vrany@labware.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