Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch] [python] PR python/15461 (gate architecture calls)
Date: Wed, 28 Aug 2013 15:15:00 -0000	[thread overview]
Message-ID: <521E1419.5040404@redhat.com> (raw)
In-Reply-To: <87k3j5x3yq.fsf@fleche.redhat.com>

On 28/08/13 15:52, Tom Tromey wrote:
>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
> 
> Phil> This patch gates calls to architecture.name and
> Phil> architecture.disassemble.  If the underlying GDB architecture is NULL,
> Phil> calls to those Python functions will result in an assert call.
> 
> Thanks.
> 
> Phil> +/* Require a valid Architecture.  */
> Phil> +#define ARCHPY_REQUIRE_VALID (arch_obj, arch)		\
> Phil> +  do {							\
> Phil> +    arch = arch_object_to_gdbarch (arch_obj);		\
> Phil> +    if (arch == NULL)					\
> Phil> +      error (_("Architecture is invalid."));		\
> Phil> +  } while (0)
> 
> I think it would be simpler to either:
> 
> * Have this set the python exception and not call error, or
> * Likewise but just have it be done in arch_object_to_gdbarch.
> 
> With the current approach you have to have a try/catch and then throw an
> exception; but really all you want is to set the python exception --
> which is cheaper to do directly.

I don't disagree on the efficiency argument, but my goal here was to
follow the pattern that other objects use to determine validity of the
underlying GDB data. To bring a sense of uniformity to how we do
things in Python. So how we check a gdb.Frame's, et al, validity, the
pattern will be the same, as far as possible, for other objects.  In
that sense, to me at least, the uniformity of how we do this trumps
expectancy of efficiency. I don't really want to argue the point too
much, as I really don't have very strong feelings either way.

Additionally, I could only see this routine happening in the test-case
derived from the bug, so I think this code would rarely run.

Cheers,

Phil


  reply	other threads:[~2013-08-28 15:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 12:04 Phil Muldoon
2013-08-28 14:52 ` Tom Tromey
2013-08-28 15:15   ` Phil Muldoon [this message]
2013-08-28 15:54     ` Tom Tromey
2013-08-29 11:15       ` Phil Muldoon
2013-08-29 14:58         ` Tom Tromey
2013-08-30 10:13           ` Phil Muldoon
2013-08-28 17:54 ` Tom Tromey
2013-08-28 18:14   ` Paul_Koning
2013-08-28 18:45     ` Phil Muldoon

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=521E1419.5040404@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@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