From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2472 invoked by alias); 19 Dec 2006 19:09:11 -0000 Received: (qmail 2464 invoked by uid 22791); 19 Dec 2006 19:09:10 -0000 X-Spam-Check-By: sourceware.org Received: from intrepid.190.195.192.in-addr.arpa (HELO intrepid.intrepid.com) (192.195.190.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Dec 2006 19:09:03 +0000 Received: from DELORIAN ([10.10.10.10]) by intrepid.intrepid.com (8.13.8/8.13.8) with ESMTP id kBJJ8aHi000935; Tue, 19 Dec 2006 11:08:39 -0800 From: "Gary Funck" To: Cc: "'Daniel Jacobowitz'" , "'Jim Wilson'" , "'Jim Blandy'" Subject: RE: how to support C type qualifiers applied to arrays? Date: Tue, 19 Dec 2006 19:09:00 -0000 Message-ID: <001301c723a1$1f170e60$0a0a0a0a@DELORIAN> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00177.txt.bz2 Jim Blandy wrote: > > "Gary Funck" writes: > > The main difficulty is that GCC doesn't create new qualified > > types for declarations. Rather, it sets TREE_READONLY() > > and TREE_THIS_VOLATILE() in the DECL node for declarations > > such as: > > > > volatile int A[10]; > > Ugh. That's a shame. Can't dwarf2out.c fix things up as it builds > the tree of struct die_structs from the GCC 'tree' type tree? In theory, it should be possible. I worked on this a bit, but I think to do it right, this fix will require contribution/direction from someone more conversant in the GCC front-end, and more knowledgeable about how the other language front-ends use both the DWARF 2 generation routines, and the extent to which they depend upon the type information remaining in its current form. Three approaches to fixing the front end to create appropriate DWARF 2 information come to mind: (1) Change the GCC front-end, so that when it creates type information and associates the type information with a declaration that it fully qualifies the type definition, in a way that preserves language semantics, yet also ensures that the correct DWARF 2 information is generated for qualified types. (2) Create the fully qualified type definition in dwarf2out.c (probably in routines that handle DECL items such as gen_formal_parameter_die(), gen_variable_die() and gen_field_die()). There are two likely sub-approaches: (i) keep this fully qualified type definition on the side, parallel to the existing type definition structure, or (ii) smash the new fully qualified type into the DECL node's TREE_TYPE() value. Keeping a parallel definition may be difficult because various parts of dwarfout.c may need to refer back to the DECL node's type value, and all places that do this will have to be found and fixed. Cross-type references and typedef's create another set of problems. Rewriting the declaration's type value is the most straightforward, but runs the risk of violating various assumptions made by the language front-ends, and will require a rather elaborate "deep copy" mechanism to make sure the fix up is done correctly. (3) Run a final pass over the internal DWARF tree built within dwarfout.c to fix up the type qualifiers, basically propagating the const_ and volatile_ qualifiers down to lower levels as required. This is probably doable, but will slow down DWARF generation for all compilations, even if most compilations seldom use "const" and "volatile" (and other qualifiers, such as UPC's "shared", "strict", and "relaxed"). In this case, it seems that dwarf2out.c is fixing representation issues that more correctly should be solved in the front-end. Given the tradeoffs, choice (1) above, where the type description is fully qualified at the time the type is bound to the DECL item, seems more correct, but may impact the correct operation of the various language front-ends and therefore will require more care and more study. Choice (2) is perhaps a bad compromise, and choice (3) is likely workable, but kludgy.