From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32398 invoked by alias); 6 Sep 2008 00:38:04 -0000 Received: (qmail 32380 invoked by uid 22791); 6 Sep 2008 00:38:03 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Sep 2008 00:37:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C82A72A9741; Fri, 5 Sep 2008 20:37:26 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ulr07eHTTLZf; Fri, 5 Sep 2008 20:37:26 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 917832A973F; Fri, 5 Sep 2008 20:37:26 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A355AE7ACD; Sat, 6 Sep 2008 02:37:24 +0200 (CEST) Date: Sat, 06 Sep 2008 00:38:00 -0000 From: Joel Brobecker To: uweigand@de.ibm.com Cc: gdb-patches@sourceware.org Subject: Re: [rfc][21/37] Eliminate builtin_type_ macros: Platform-neutral builtin_type_void Message-ID: <20080906003724.GK15267@adacore.com> References: <20080831175045.128504000@de.ibm.com> <20080831175130.615909000@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080831175130.615909000@de.ibm.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00118.txt.bz2 > However, this problem can be fixed by simply making sure that noone > ever calls lookup_pointer_type, lookup_reference_type, or lookup_function_type > on the platform-neutral builtin_type_void type. I am really concerned that, one day, we will miss someone re-introducing a call to one of these functions with the builtin_type_void type It would be really useful to do whatever we can to prevent this from happening. I don't want to add a field in our type structure to mark the types that are architecture-specific, since that would have a noticeable memory cost just for a few specific types. So about the following, not ideal but probably good enough: - Add a new function architecture_neutral_builtin_type () that returns true/non-zero if the given type is one of the builtin types defined by gdbtypes (just doing a pointer check against every builtin_type_* that we have) - Add an assertion in lookup_pointer_type, lookup_reference_type, and lookup_function_type using the function above. - Add a comment a the beginning of the builtin_type section explaining that the following types are architecture neutral, and that computing pointer/reference/function types should not be performed on them. Explicitly remind the reader that when adding a new builtin type there, he should also update the check in architecture_neutral_builtin_type. Another option is to generate the builtin types and the associated architecture_neutral_builtin_type function a-la gdbarch. Probably cleaner, as less error prone. This doesn't have to be done as part of this patch, though, especially since this is open to discussion. Perhaps shortly after this patch set is checked in, we could make sure to follow up on that? -- Joel