From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11882 invoked by alias); 2 Jan 2012 10:17:25 -0000 Received: (qmail 11869 invoked by uid 22791); 2 Jan 2012 10:17:24 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Jan 2012 10:17:03 +0000 Received: by qcsd17 with SMTP id d17so10549528qcs.0 for ; Mon, 02 Jan 2012 02:17:03 -0800 (PST) Received: by 10.229.78.209 with SMTP id m17mr17418294qck.80.1325499423230; Mon, 02 Jan 2012 02:17:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.209 with SMTP id m17mr17418277qck.80.1325499422339; Mon, 02 Jan 2012 02:17:02 -0800 (PST) Received: by 10.224.72.210 with HTTP; Mon, 2 Jan 2012 02:17:02 -0800 (PST) In-Reply-To: References: Date: Mon, 02 Jan 2012 10:17:00 -0000 Message-ID: Subject: Re: [RFC] A new command 'grep' From: Siva Chandra To: gdb-patches@sourceware.org Cc: Eli Zaretskii , Kevin Pouget X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2012-01/txt/msg00026.txt.bz2 Hello, Thanks for taking a look. My comments inline. Eli > I think this is the first time we receive a proposal for a command Eli > implemented in Python. =A0Perhaps there's a place to discuss whether Eli > some policy is in order in this regard. =A0E.g., the command will be Eli > unavailable in non-Python builds, which at least needs to be Eli > documented. =A0There may be other aspects that are worth discussing. This is not the first, I submitted RFC another command called 'explore' few weeks back implemented in Python :-) Kevin > I'm also curious about that, and maybe first of all, is there a Pyt= hon Kevin > specific coding convention likely to be enforced in GNU projects Kevin > and/or GDB? I couldn't locate any GNU coding conventions for Python. Hence, I tried to follow the convention I could reverse engineer from the other Python files in python/lib/gdb/command directory. Kevin > There was a discussion a few months ago about "Implementation of pi= pe Kevin > to pass GDB's command output to the shell" [1] which would allow to Kevin > use the 'real' grep to do a similar job, but I'm not sure about the Kevin > status of this patch, it seems not to be in the trunk yet, according Kevin > to the ChangeLog. I agree that if we can pass GDB output to shell, a lot of functionality in this command is redundant. I was unaware of this work. However, I have a part of this command extensible. When 'grepping' through unions, the user can define a field selector for the union and the command will select only that field to grep through. I have found this very useful in understanding GCC data structures. Another point is that if we rely the shell grep and the GDB print command, it cannot grep through pointer values. Kevin > I didn't really look in depth at the sources, but based on you email Kevin > description, I wonder how it differs from a generic code like that Kevin > (not tested) Kevin > Kevin > (gdb) grep int ss Kevin > ss.int_val =3D (int) 10 Kevin > Kevin > #assume set print pretty on Kevin > Kevin > command =3D "print %s" % ss Kevin > to_grep =3D "int" Kevin > Kevin > out =3D gdb.execute (command, to_string=3DTrue) Kevin > for line in out.split("\n") Kevin > =A0if to_grep in line: Kevin > =A0 =A0print line This does most of the job again but for the two points I mentioned above. And again, I didn't think of this approach before. It seems to me that we can either have this command I submitted in Python, or extend the existing commands to support user defined plugins. I am a newcomer to GDB code and its development: I am probably not thinking very correctly. About the name of the command itself, I am OK with 'lookup' instead of 'grep'. I favor 'grep' over 'lookup' because 'lookup' kind of implies (probably just in my mind) to return a boolean value. Thanks, Siva Chandra