From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7117 invoked by alias); 17 Nov 2005 12:10:36 -0000 Received: (qmail 7107 invoked by uid 22791); 17 Nov 2005 12:10:34 -0000 Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 12:10:34 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-02.spheriq.net with ESMTP id jAHCASe7002327 for ; Thu, 17 Nov 2005 12:10:29 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-02.spheriq.net with ESMTP id jAHCAR5q020682 for ; Thu, 17 Nov 2005 12:10:28 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id jAHCAN1Q018429 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Nov 2005 12:10:27 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BE108DA46; Thu, 17 Nov 2005 12:10:22 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id D184A4743F; Thu, 17 Nov 2005 12:13:21 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9337D75994; Thu, 17 Nov 2005 12:13:21 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id CFFA34741B; Thu, 17 Nov 2005 12:13:19 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ44476 (AUTH "andrew stubbs"); Thu, 17 Nov 2005 12:10:17 GMT Message-ID: <437C728E.70601@st.com> Date: Thu, 17 Nov 2005 12:42:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Jim Blandy Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [PATCH] keep-variable command References: <437B44E1.8090008@st.com> <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> In-Reply-To: <8f2776cb0511161528y372fde8cuaa7ddecf863f277a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 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/msg00274.txt.bz2 Jim Blandy wrote: > - Converting types to strings needs to be done in a > language-independent manner. It's a shame that types don't seem to > point to a language. But it would be better to use LA_PRINT_TYPE > than to build the name by hand. That prints to a stream. Is there a way to make it 'print' to a buffer? I haven't studied it in depth. > - Types can be local to some scope. Even if you print out a type's > name, how can you discover what scope to re-parse it in? Right now > you're just getting whatever happens to be in > expression_context_block, right? Yes, but the variables are fixed up lazily. In theory, if the user doesn't access it until it makes sense then there will be no problem. Of course, if they just say 'show conv' then some variables may well not find types. > Do you really need all this? Can you tell us more about the situation? We have a number of scripts which want to keep values regardless of what happens to the symbol tables - they mostly describe the configuration of the target (location of memory mapped registers, that kind of thing). I think they are all just char, int or pointer variants of those. This worked OK for a while without anything special (we just didn't delete them), but the type fixing was in response to some evil crashing bugs we had. I discovered it had been working more by chance than design and did something about it - it is always wrong to make assumptions about pointers into tables that are being rebuilt. The fact that made it work for other types was something of a freebie. Regardless of whether I really _need_ all of it I rather _like_ the fact that it Just Works ... mostly. Andrew