From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32045 invoked by alias); 8 Oct 2007 11:19:42 -0000 Received: (qmail 32035 invoked by uid 22791); 8 Oct 2007 11:19:41 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Oct 2007 11:19:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l98BJb2X025440 for ; Mon, 8 Oct 2007 11:19:37 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l98BJai12261164 for ; Mon, 8 Oct 2007 13:19:36 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l98BJaWS008161 for ; Mon, 8 Oct 2007 13:19:36 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l98BJalB008158; Mon, 8 Oct 2007 13:19:36 +0200 Message-Id: <200710081119.l98BJalB008158@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 8 Oct 2007 13:19:36 +0200 Subject: Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING To: eliz@gnu.org Date: Mon, 08 Oct 2007 11:19:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Eli Zaretskii" at Oct 06, 2007 09:16:35 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2007-10/txt/msg00127.txt.bz2 Eli Zaretskii wrote; > This part is almost okay; I have a few minor comments: > > . The ChangeLog entry needs to state the name(s) of the node(s) where > you make the changes (in parens, as if they were names of > functions). Sure, I'll do that. > . Please put the function prototypes where you describe them. For > example: > > > -@item SOFUN_ADDRESS_MAYBE_MISSING > > -@findex SOFUN_ADDRESS_MAYBE_MISSING > > +@item int gdbarch_sofun_address_maybe_missing > > +@findex gdbarch_sofun_address_maybe_missing > > The old SOFUN_ADDRESS_MAYBE_MISSING was a macro without arguments, but > the new gdbarch_sofun_address_maybe_missing is a function that accepts > arguments. The @item line should show the full prototype of the > function, including the type(s) of its argument(s). Well, the sofun_address_maybe_missing gdbarch entry is of type "v", i.e. it is a simple variable of type "int", not a function. That means the argument to set_gdbarch_sofun_address_maybe_missing is a simple boolean. I had thought the documentation for gdbarch entries should refer to the entity that you pass to the set_gdbarch_ function; after all that is what the -tdep.c programmer writes. On the other hand, the accessor function gdbarch_sofun_address_maybe_missing does have an argument, namely the gdbarch that is being queried. I see that some of the other entries do show these arguments, so you could say it should be added in the case as well. I guess the question is, what is the entity that the documentation should specify for gdbarch entries: - the gdbarch_... accessor function or - the argument passed to the set_gdbarch_... routine I'll be happy to do it either way, please let me know which you prefer. > . Some of the changes were too mechanical: replacing a macro with a > function sometimes needs more elaborate changes in the text to > avoid unclear or incorrect wording: This is because I was describing a boolean "int" value, not a function. If we're to describe the access functions, that needs to be rephrased accordingly, of course. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com