From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19316 invoked by alias); 27 Jul 2010 16:26:01 -0000 Received: (qmail 19296 invoked by uid 22791); 27 Jul 2010 16:25:56 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jul 2010 16:25:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E6DA92BAC02; Tue, 27 Jul 2010 12:25:49 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hREGM89UbABn; Tue, 27 Jul 2010 12:25:49 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AF4422BAC01; Tue, 27 Jul 2010 12:25:49 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CFB8EF58FA; Tue, 27 Jul 2010 09:25:45 -0700 (PDT) Date: Tue, 27 Jul 2010 16:26:00 -0000 From: Joel Brobecker To: Phil Muldoon Cc: gdb-patches ml Subject: Re: [patch] Add solib_address and decode_line Python functionality Message-ID: <20100727162545.GF13267@adacore.com> References: <4C44728D.4040408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C44728D.4040408@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2010-07/txt/msg00432.txt.bz2 Just my 2 cents on the API and doc... > solib_address -- lookup an address and if it resides in an solib > reports that libs name, or None. IMO, the name that was chosen for this function implies the opposite of what it does (it implies that it returns the solib (base?) address). I would personally prefer solib_name or solib_name_from_address. > +for Python commands (@pxref{Commands In Python}). The expected > +format of @var{expression} is: > + > +@table @code > +@item FILE:LINENUM > +A location indicated at that line in that file. > +@item FUNCTION > +A location at the beginning of that function. > +@item FILE:FUNCTION > +A location to distinguish among like-named static functions. > +@item ADDRESS > +A location containing that address. > +@item VARIABLE > +A location containing that variable. > +@end table > +@end defun ISTM that we would be better off not duplicating the various forms a linespec can take. How about using a cross reference? -- Joel