From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14914 invoked by alias); 19 Jun 2006 12:58:41 -0000 Received: (qmail 14906 invoked by uid 22791); 19 Jun 2006 12:58:40 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 12:58:31 +0000 Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id k5JCvfZ8028669; Mon, 19 Jun 2006 13:57:41 +0100 (BST) Received: from pc960.cambridge.arm.com ([10.1.255.211]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Jun 2006 13:57:41 +0100 Subject: Re: [PATCH] Interpret DW_TAG_unspecified_type as void From: Richard Earnshaw To: Mark Kettenis Cc: Julian Brown , gdb-patches@sourceware.org, Daniel Jacobowitz In-Reply-To: <200606180114.k5I1E5nu017691@elgar.sibelius.xs4all.nl> References: <448969B2.9010202@codesourcery.com> <200606180114.k5I1E5nu017691@elgar.sibelius.xs4all.nl> Content-Type: text/plain Message-Id: <1150721856.6312.8.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Jun 2006 12:58:00 -0000 Content-Transfer-Encoding: 7bit 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: 2006-06/txt/msg00269.txt.bz2 On Sun, 2006-06-18 at 02:14, Mark Kettenis wrote: > > Date: Fri, 09 Jun 2006 13:29:38 +0100 > > From: Julian Brown > > > > Hi, > > > > This is part of a series of patches from a CodeSourcery branch which > > enable the output of ARM's RVCT 2.2 compiler to be debugged with gdb. > > > > This patch handles the C/C++ interpretation of the DWARF 3 construct > > DW_TAG_unspecified_type as void. This is used in representing e.g. > > pointer-to-void types. Other languages will currently be handled in > > exactly the same way; though I'm not entirely sure if that's a sensible > > default, I don't know what would be better. (Re: section 5.2 of the > > DWARF 3 doc.) > > > > Tested natively on x86_64-unknown-linux-gnu and cross to arm-none-eabi > > with no change in results. Tests against the ARM compiler are improved > > somewhat. > > > > OK to apply? > > I haven't looked into what the DWARF spec actually says, but > traditionally unspecified types in C default to 'int', not 'void'. 5.2 Unspecified Type Entries Some languages have constructs in which a type may be left unspecified or the absence of a type may be explicitly indicated. An unspecified (implicit, unknown, ambiguous or nonexistent) type is represented by a debugging information entry with the tag DW_TAG_unspecified_type. If a name has been given to the type, then the corresponding unspecified type entry has a DW_AT_name attribute whose value is a null-terminated string containing the name as it appears in the source program. The interpretation of this debugging information entry is intentionally left flexible to allow it to be interpreted appropriately in different languages. For example, in C and C++ the language implementation can provide an unspecified type entry with the name "void" which can be referenced by the type attribute of pointer types and typedef declarations for 'void' (see Sections 5.3 and 5.4, respectively). As another example, in Ada such an unspecified type entry can be referred to by the type attribute of an access type where the denoted type is incomplete (the name is declared as a type but the definition is deferred to a separate compilation unit). So in this case we do mean void (in particular void* means pointer to unspecified type). The 'defaults to int' is more an implicit type than an unspecified type, and the third paragraph above makes it cleat that void is what is meant for C. R.