From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30259 invoked by alias); 27 Jan 2006 17:53:54 -0000 Received: (qmail 30251 invoked by uid 22791); 27 Jan 2006 17:53:53 -0000 X-Spam-Check-By: sourceware.org Received: from gandalf.inter.net.il (HELO gandalf.inter.net.il) (192.114.186.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 17:53:52 +0000 Received: from nitzan.inter.net.il (nitzan.inter.net.il [192.114.186.20]) by gandalf.inter.net.il (MOS 3.7.1-GA) with ESMTP id HRW09909; Fri, 27 Jan 2006 19:53:46 +0200 (IST) Received: from HOME-C4E4A596F7 (IGLD-83-130-255-5.inter.net.il [83.130.255.5]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id COV37913 (AUTH halo1); Fri, 27 Jan 2006 19:53:44 +0200 (IST) Date: Fri, 27 Jan 2006 17:53:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org CC: Andrew STUBBS , Jim Blandy In-reply-to: <20060122213118.GH27224@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 22 Jan 2006 16:31:18 -0500) Subject: Re: [RFC] Alternate approach to keeping convenience variables Reply-to: Eli Zaretskii References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> <43835114.5060401@st.com> <20051209205923.GA21331@nevyn.them.org> <20060122213118.GH27224@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00447.txt.bz2 > Date: Sun, 22 Jan 2006 16:31:18 -0500 > From: Daniel Jacobowitz > Cc: Andrew STUBBS , Jim Blandy > > This version of the patch addresses all the comments I've received, > except for: > > - TYPE_ZALLOC. I think this is more appropriate as a macro, > personally, though I wouldn't argue too loudly if someone wanted to > functionify it at the same time as TYPE_ALLOC. > > GDB developers seem to have developed an allergy to C macros that > I just don't understand. They're not _inherently_ obfuscating > or evil! They can be both useful and elegant. FWIW, I never understood the ``macros are bad, m'kay?'' policy, either. > - gdbint; I couldn't find a vaguely appropriate place to add a > description of this, and I don't think it's such a fascinating > approach that it's worth creating a new section for. At this point, I wouldn't bother about the structure of gdbint.texinfo, just about getting the information in there. The structure is a mess anyhow; in particular, there are too few nodes and too many sections that lack a node. But it is useless to try to fix structure when the full extent of the information is not known even approximately. So, if you have time, just add a section somewhere, even if it is short. I think it's important to document this piece of information. > I noticed in the course of updating gdb.texinfo that there are still a > whole lot of references to VxWorks. GDB no longer supports VxWorks, > and current versions of VxWorks don't speak a compatible protocol to > the one that GDB used to support, anyway. Ripping this out will be a > little more work than I have time for at the moment though. Thanks for the heads-up, I will try to remember to do that when I have my next Rainy Day(tm). > Index: src/gdb/doc/gdb.texinfo > =================================================================== > --- src.orig/gdb/doc/gdb.texinfo 2005-12-03 07:44:31.000000000 -0500 > +++ src/gdb/doc/gdb.texinfo 2006-01-22 16:20:46.000000000 -0500 > @@ -10821,11 +10821,11 @@ table and program to run from the same f > @code{symbol-file} with no argument clears out @value{GDBN} information on your > program's symbol table. > > -The @code{symbol-file} command causes @value{GDBN} to forget the contents > -of its convenience variables, the value history, and all breakpoints and > -auto-display expressions. This is because they may contain pointers to > -the internal data recording symbols and data types, which are part of > -the old symbol table data being discarded inside @value{GDBN}. > +The @code{symbol-file} command causes @value{GDBN} to forget the contents of > +some breakpoints and auto-display expressions. This is because they may > +contain pointers to the internal data recording symbols and data types, > +which are part of the old symbol table data being discarded inside > +@value{GDBN}. > > @code{symbol-file} does not repeat if you press @key{RET} again after > executing it once. This part is approved. I also skimmed the other parts of the patch and didn't see anything I would disapprove.