From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8254 invoked by alias); 16 Nov 2005 20:09:16 -0000 Received: (qmail 8197 invoked by uid 22791); 16 Nov 2005 20:09:13 -0000 Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 16 Nov 2005 20:09:13 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-33-244.inter.net.il [80.230.33.244]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BYR69830 (AUTH halo1); Wed, 16 Nov 2005 22:09:10 +0200 (IST) Date: Wed, 16 Nov 2005 20:26:00 -0000 Message-Id: From: Eli Zaretskii To: Andrew STUBBS CC: gdb-patches@sources.redhat.com In-reply-to: <437B44E1.8090008@st.com> (message from Andrew STUBBS on Wed, 16 Nov 2005 14:40:33 +0000) Subject: Re: [PATCH] keep-variable command Reply-to: Eli Zaretskii References: <437B44E1.8090008@st.com> 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-11/txt/msg00250.txt.bz2 > Date: Wed, 16 Nov 2005 14:40:33 +0000 > From: Andrew STUBBS > > +@value{GDBN} commands that wipe the symbol table, such as @samp{file} and > +@samp{symbol-file}, cause all convenience variables to be deleted - their ^^^ Please use "---" (3 dashes in a row) to produce a dash (as opposed to the minus sign). > +types are lost so their value would become meaningless. This can be avoided > +using the @samp{keep-variable} command below. It's possible this is something I never knew about: is it actually correct that _all_ convenience variables are deleted when `file' is used? The explanation above about their types being lost doesn't make sense to me; can you explain? For example, if I define a variable that holds an integer number, why would its type become meaningless? > +The next time the variable is accessed (by whatever means) @value{GDBN} will > +attempt to find a type, in the current symbol table, with the same name as > +the type used previously. It does not check whether the new type is in any > +way compatible with the old type. > + > +If a suitable type does not exist (at the time the variable is accessed) then > +@value{GDBN} will print a message and reset the value to @code{void}. > + > +If the symbol table is destroyed and recreated multiple times, the content > +of the intermediate tables has no effect, @emph{provided that the variable > +is not accessed while they are loaded}. Does this description assume that convenience variables point, or are somehow related, to the symbol table? If so, why does this assumption hold for every convenience variable? I can think of a convenience variable that has no relation whatsoever to the symbol table; how does such a variable fit into the above scheme?