This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] [python] PR python/15461 (gate architecture calls)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]