From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26988 invoked by alias); 10 Dec 2005 09:06:55 -0000 Received: (qmail 26936 invoked by uid 22791); 10 Dec 2005 09:06:54 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 Dec 2005 09:06:54 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-42-206.inter.net.il [80.230.42.206]) by romy.inter.net.il (MOS 3.7.2-GA) with ESMTP id DDL23080 (AUTH halo1); Sat, 10 Dec 2005 11:06:49 +0200 (IST) Date: Sun, 11 Dec 2005 19:17:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sources.redhat.com CC: Andrew STUBBS In-reply-to: <20051209205923.GA21331@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 9 Dec 2005 15:59:23 -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> 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: 2005-12/txt/msg00199.txt.bz2 > Date: Fri, 9 Dec 2005 15:59:23 -0500 > From: Daniel Jacobowitz > Cc: Jim Blandy , gdb-patches@sources.redhat.com > > The tracepoint.c change is necessary for default.exp. To see why, try > this: > $ gdb > (gdb) show convenience > $trace_frame = -1 > $tpnum = 0 > > vs. > $ gdb /bin/ls > (gdb) show convenience > No debugger convenience variables now defined. > Convenience variables have names starting with "$"; > use "set" as in "set $foo = 5" to define them. > > If you want the inconsistency resolve the other way round, please > holler. I understand that, with your change, GDB will behave as in the second example, even if no executable file was loaded yet, yes? If so, I'm for this change: I think GDB shouldn't show tracepoint-related variables unless tracepoints are actually being used. > How does this look? Looks good to me, thanks. A few minor comments: . copy_type_recursive looks very much like a kind of deep copy. Is it? If so, perhaps we should call the function accordingly. . Do you think we need to add or change anything in the manual as result of this patch? . How about adding a few words in gdbint.texinfo to describe the strategy of your solution?