From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7794 invoked by alias); 22 Nov 2005 17:14:13 -0000 Received: (qmail 7782 invoked by uid 22791); 22 Nov 2005 17:14:12 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Nov 2005 17:14:10 +0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-02.spheriq.net with ESMTP id jAMHDkog015442 for ; Tue, 22 Nov 2005 17:13:46 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-03.spheriq.net with ESMTP id jAMHDjSP020031 for ; Tue, 22 Nov 2005 17:13:45 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id jAMHDhkH013564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 22 Nov 2005 17:13:44 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 82559DA41; Tue, 22 Nov 2005 17:13:34 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id D2FF3474BB; Tue, 22 Nov 2005 17:16:35 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7A60075999; Tue, 22 Nov 2005 17:16:35 +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 01E9C474BB; Tue, 22 Nov 2005 17:16:34 +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 CGZ78828 (AUTH "andrew stubbs"); Tue, 22 Nov 2005 17:13:32 GMT Message-ID: <43835114.5060401@st.com> Date: Tue, 22 Nov 2005 19:27:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] keeping convenience variables (take 2) References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> In-Reply-To: <8f2776cb0511212138g2adef40cr1632365c00e3bebc@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 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-11/txt/msg00414.txt.bz2 Jim Blandy wrote: > I may be missing something, be patient: > > If I understand the original motivation for this, you don't actually > need to keep around any values that aren't using the builtin types. > Or at least, that could be using the built-in types; it wasn't clear > whether they actually did. Yes, most likely they are all builtin types, but when I first did the work (in 5.3) I found that it could not be assumed that the builtin types would stay in the same place. I do not remember under what circumstances I observed this. So I fixed it and the result was that we got 'textual compatibility' of all other types for free. Now it does appear that builtin types can be safely left alone - there have been many changes to the code in this area. > I'm uncomfortable with this whole "print type name and then re-parse > later" approach. I think it's a real kludge. And the fact that it > doesn't seem really necessary for the problem that originally > motivated the change is a red flag, it seems to me. You may be right - I probably don't _need_ it. However, it does work - it provides this 'textual compatibility' very effectively. A better way to print the type name might be nice though. Your point about it not being necessary might be a good reason not to do something in the first place, but it is not, in itself, a good reason to disregard something that has _already_ been done (mostly anyway). This is especially true when what has been done is 'nice to have'. > I can certainly see that it's useful to keep the convenience variables > around across symfile selections and endianness switches; I just think > we should find a better way to handle the types than this. Well, we could recursively copy the entire type list for type and enclosing_type. This would certainly be enough to print the value and to use it in some expressions. I can imagine that there might be some issues because these types would exist outside of the normal type table and/or might clash with types in that table. However, this would require intimate knowledge of the value and type structures and everything they reference. Also, it would be impossible to change the value, even though the existing contents could be read, because parse_expression() wouldn't see the types. It would need a flag in the internalvar to say it would need freeing if the value changes to something else. It might then be possible to match a copied type up against new types at some point (still with all the problems of context etc.), but this does not seem pretty - not least because a lot of pointer types are generated on the fly (something parse_expression does for us in my technique). If anybody has any other suggestions or insight on these matters then that will be welcome. > If the convenience variables you set up in your script, holding > addresses and such, don't refer to the builtin types, why don't they? > Could they? I understand that changing architectures or > architectural variants affects the builtin types, but it seems more > feasible to track those changes than to try to track objfile-based > types as they disappear and reappear. Another question is 'why wouldn't they?' I make no attempt the track changes across architectural variants (other than endian) or indeed from one architecture to another. Doing that would require actual comparison of the before and after types and a type conversion of some kind. It seems much harder to me than just extracting type information (in whatever form) and keeping it or reinstating it later. Perhaps I misunderstand your point. If I understand you, I think your problem is that the conversion process is a) incomplete with respect to non-C languages; b) prone to mistakes with commonly used type-names; and c) different to how it was before. I think the first two can be fixed by means of a better name capturing technique (GDB can print this to screen, but is there a way to capture it in a string?) and by comparing more than just the name (size of base type, number of fields, perhaps some kind of checksum???). Andrew Stubbs