From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31019 invoked by alias); 9 Jun 2008 23:49:47 -0000 Received: (qmail 30996 invoked by uid 22791); 9 Jun 2008 23:49:45 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jun 2008 23:49:23 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m59NnIKF001973; Mon, 9 Jun 2008 19:49:18 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m59NnIlI009585; Mon, 9 Jun 2008 19:49:18 -0400 Received: from opsy.redhat.com (vpn-10-41.bos.redhat.com [10.16.10.41]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m59NnHgK006769; Mon, 9 Jun 2008 19:49:17 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id D917437814F; Mon, 9 Jun 2008 17:49:16 -0600 (MDT) To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org Subject: Re: Function syntax References: <20080608182128.GA6248@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Tue, 10 Jun 2008 00:00:00 -0000 In-Reply-To: <20080608182128.GA6248@caradoc.them.org> (Daniel Jacobowitz's message of "Sun\, 8 Jun 2008 14\:21\:28 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2008-06/txt/msg00178.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Tom> Recently I've been thinking that $(...) should not simply eval the Tom> '...' as a python expression. Instead, I'm leaning more toward a Tom> function registry approach. I have two reasons for this. Daniel> This sounds good to me. Good :) I actually went ahead and implemented this a little while back. Daniel> Except we do need to define what the arguments to specified functions Daniel> are, and I want a clear answer on that point before anything goes in. Yes, I totally agree. IMO this is much more important than the various implementation details -- those can be changed much more easily than user-facing behavior. Daniel> They could be Python syntax, or some other well-defined syntax which Daniel> happens to be similar to Python. Would GDB convenience variables Daniel> work? As values or as textual substitution? Daniel> As long as we pick something and document it, I think the choice of Daniel> what to pick is not too significant. [...] Daniel> Making them complete on a string seems too awkward when writing such Daniel> things. At function-writing time it would be easier (but less Daniel> flexible) to specify a list of arguments and have GDB handle the Daniel> breaking up into words... I know we discussed this before but I can't Daniel> remember the details now. The way this works right now is that the first word is stripped from the text between the parens. This is the function name and is looked up in an internal table. The rest is passed, untranslated, as an argument. We talked about doing more parsing here for commands, and I guess by extension functions. But I have kind of come around to the other point of view -- leave the argument as a string and let the callee deal with it. One reason I prefer this is that it lets new functions require less syntax. For instance, consider my canonical example of a function that looks to see if the caller's stack frame matches the argument: break somewhere if $(caller-is somewhere_else) If we were dealing with sub-expressions or the like, this would have to be a string. That just seems less gdb-ish to me -- though of course this argument is somewhat weak in that other folks may have a different idea about the nature of gdb's grammar. I see your point about convenience variables. They would not be automatically interpolated. On the other hand, nothing prevents a python function from evalling an argument as a gdb expression. Another reason I prefer this approach is that in general it is simpler to write stuff in Python rather than C. I already plan to ship a library of useful Python functions with this gdb -- adding more utility code to handle parsing, completion, etc, is no big deal. Tom> * I don't want to use $python(...) -- but I was wondering, doesn't Tom> this already have a meaning if 'python' happens to be a Tom> function-pointer-valued convenience variable? Daniel> Yes, but this is always an issue defining new predefined convenience Daniel> variables since they share a namespace with user variables. I think this is an argument to keep the $(fn) syntax -- it would be nice if these functions had a separate namespace. One reason in particular I would like that is that I think we ought to ship a lot of built-in ones, and it would be nice not to trample all over the user namespace. Tom