Re: [PATCH] New python function gdb.lookup_objfile.

[Doug Evans <dje@google.com>]

On Tue, Dec 9, 2014 at 2:49 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> On 09/12/14 02:39, Doug Evans wrote:
>> Hi.
>>
>> This patch implements a new python function gdb.lookup_objfile.
>> It provides the ability to look up an objfile given a file name
>> or build id.
>>
>> While one could call gdb.objfiles() and then scan over that,
>> it requires construction of the list, and with *lots* of objfiles
>> it is a bit cumbersome.
>>
>> Regression tested on amd64-linux.
>
> Thanks.
>
>
>> +@findex gdb.lookup_objfile
>> +@defun gdb.lookup_objfile (name @r{[}, by_build_id{]})
>> +Look up @var{name}, which is a file name, in the list of objfiles
>> +for the current program space (@pxref{Progspaces In Python}).
>> +If the objfile is not found then a Python @code{ValueError} exception
>> +is thrown.
>
>
> Do wildcard or partial matches work? It would be excellent if they
> did, and if so, a note in the documentation.  If not, how much work do
> you think it would be to have this functionality?

I'm using gdb's standard routine for filename matches, so yeah partial
names work.
I'll spiff up the docs a bit (hopefully just a cut-n-paste-n-tweak of
existing docs on the subject ... :-))

> A soft objection.  Not a fan of functions that return an Exception on
> "item not found" personally.  I prefer to return None, and save
> exceptions for errors.  But I understand that in some projects this
> paradigm is used.

I'm kinda indifferent, and was just "going with the flow" here.
Some existing lookup routines throw an exception and some return None.
Throwing an exception seemed more Pythonic.

>> +{
>> +  static char *keywords[] = { "name", "by_build_id", NULL };
>> +  const char *name;
>> +  PyObject *by_build_id_obj = NULL;
>> +  int by_build_id;
>> +  struct objfile *objfile;
>> +
>> +  if (! PyArg_ParseTupleAndKeywords (args, kw, "s|O!", keywords,
>> +                     &name, &PyBool_Type, &by_build_id_obj))
>> +    return NULL;
>
> If "name" is an empty string should we just immediately return an
> exception here?  There are some operations later that depend on
> strlen.  I had a quick look, and it seems none of the functions have a
> real hard issue with zero string lookups, but it might be best to
> check here first.

Yeah, but it's more code, and Consistency Is Good would then make me
want to do an initial check for empty strings in every lookup routine.