From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17441 invoked by alias); 9 Dec 2014 17:23:42 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17426 invoked by uid 89); 9 Dec 2014 17:23:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vc0-f176.google.com Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com) (209.85.220.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 09 Dec 2014 17:23:39 +0000 Received: by mail-vc0-f176.google.com with SMTP id hq12so498495vcb.21 for ; Tue, 09 Dec 2014 09:23:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=evTQzw1YvVgBPqBSYDw4a0TtTj8Ot2Sbae+QqWPwRZ4=; b=NnX2ESwC6YDVjXErYQiRCPvdy3JRRk8UXAMM4LFjRm/LcbQu51i2iez233zT5rnb9N TRHkd1vtLMlI9VaiDD9xVAeU1f7HtbTtQUbeW0/mW2yZ5m+cnpn5jRqJ2/3yIsbSmsmk LT++pN07Ehc5wtFl0MEjmNbRhZr0xXAsyYWEA901ODxL7V52FZzqO/jJ+lOCw4Xgjz6g I3bVcM/YCq3X9gOPOY/mop1pHBPTVLQpSGX6JRH14ynWwk/sQ6yWNUBuoUBkRfvuV0Xn PhnNieH6bk2dQ1AuMsGTdNlYwklMey3TCrAZfAjYGDmoDQUoPC2YlosSUMOrTwV+s46M lB7Q== X-Gm-Message-State: ALoCoQnNv7rutkPwrGZAD38llqq40+U+uF2tvVC04JQkCrfEcIG0jcoaDaJormSvIfwpDDnKBAh/ MIME-Version: 1.0 X-Received: by 10.52.29.172 with SMTP id l12mr1421693vdh.33.1418145817544; Tue, 09 Dec 2014 09:23:37 -0800 (PST) Received: by 10.52.114.101 with HTTP; Tue, 9 Dec 2014 09:23:37 -0800 (PST) In-Reply-To: <5486D3D4.5060202@redhat.com> References: <5486D3D4.5060202@redhat.com> Date: Tue, 09 Dec 2014 17:23:00 -0000 Message-ID: Subject: Re: [PATCH] New python function gdb.lookup_objfile. From: Doug Evans To: Phil Muldoon Cc: gdb-patches , Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00200.txt.bz2 On Tue, Dec 9, 2014 at 2:49 AM, Phil Muldoon 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.