From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3598 invoked by alias); 6 Oct 2007 07:16:44 -0000 Received: (qmail 3566 invoked by uid 22791); 6 Oct 2007 07:16:42 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Oct 2007 07:16:39 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-247-203.inter.net.il [83.130.247.203]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id JAU78534 (AUTH halo1); Sat, 6 Oct 2007 09:16:24 +0200 (IST) Date: Sat, 06 Oct 2007 07:16:00 -0000 Message-Id: From: Eli Zaretskii To: "Ulrich Weigand" CC: gdb-patches@sourceware.org In-reply-to: <200710051806.l95I6K3k030029@d12av02.megacenter.de.ibm.com> (uweigand@de.ibm.com) Subject: Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING Reply-to: Eli Zaretskii References: <200710051806.l95I6K3k030029@d12av02.megacenter.de.ibm.com> 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: 2007-10/txt/msg00081.txt.bz2 > Date: Fri, 5 Oct 2007 20:06:20 +0200 (CEST) > From: "Ulrich Weigand" > > this removes the SOFUN_ADDRESS_MAYBE_MISSING target macro. There are > two main parts to this: > > - struct minimal_symbol used to have the member "filename" present > only when SOFUN_ADDRESS_MAYBE_MISSING was true. The patch changes > this to make the member always available. Code used to initialize > and use those filenames is now also enabled unconditionally. (This > should not actually change the behaviour of GDB on any target.) > > - Instead of the SOFUN_ADDRESS_MAYBE_MISSING macro, a new gdbarch > variable gdbarch_sofun_address_maybe_missing is introduces. All > places where GDB behaviour depended on SOFUN_ADDRESS_MAYBE_MISSING > now look at that gdbarch variable instead. Thanks. > doc/ChangeLog: > > * gdbint.texinfo: Document gdbarch_sofun_address_maybe_missing > instead of SOFUN_ADDRESS_MAYBE_MISSING. 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). . 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). . 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: > -@code{SOFUN_ADDRESS_MAYBE_MISSING} indicates that a particular set of > +@code{gdbarch_sofun_address_maybe_missing} indicates that a particular set of A function cannot _indicate_ anything, it can return a value that indicates something. (The old text was correct because the macro was used in an #ifdef at compile time.) > -@code{SOFUN_ADDRESS_MAYBE_MISSING} means two things: > +@code{gdbarch_sofun_address_maybe_missing} means two things: Again, a function cannot _mean_ anything; please rephrase.