From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7267 invoked by alias); 3 Mar 2010 20:13:12 -0000 Received: (qmail 7251 invoked by uid 22791); 3 Mar 2010 20:13:11 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Mar 2010 20:13:07 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o23KD57Q019519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Mar 2010 15:13:05 -0500 Received: from zebedee.pink (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o23KD4ts008019; Wed, 3 Mar 2010 15:13:04 -0500 Message-ID: <4B8EC2CF.4000302@redhat.com> Date: Wed, 03 Mar 2010 20:13:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: Keith Seitz CC: java@gcc.gnu.org Subject: Re: Static class members & DWARF References: <4B8EBD25.6000901@redhat.com> In-Reply-To: <4B8EBD25.6000901@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00003.txt.bz2 On 03/03/2010 07:48 PM, Keith Seitz wrote: > Hi, > > Consider the following simple class: > > class jvstatic > { > public static int STATIC = 1; > } > > Looking at the DWARF info for this class, I see: > > <1><107>: Abbrev Number: 2 (DW_TAG_class_type) > <108> DW_AT_name : (indirect string, offset: 0xdf): jvstatic > <10c> DW_AT_byte_size : 4 > <10d> DW_AT_decl_file : 1 > <10e> DW_AT_decl_line : 0 > <10f> DW_AT_containing_type: <0x17b> > <113> DW_AT_sibling : <0x17b> > <2><117>: Abbrev Number: 3 (DW_TAG_inheritance) > <118> DW_AT_type : <0x17b> > <11c> DW_AT_data_member_location: 2 byte block: 23 0 > (DW_OP_plus_uconst: 0) > <11f> DW_AT_accessibility: 1 (public) > <2><120>: Abbrev Number: 4 (DW_TAG_member) > <121> DW_AT_name : (indirect string, offset: 0x123): STATIC > <125> DW_AT_decl_file : 1 > <126> DW_AT_decl_line : 0 > <127> DW_AT_MIPS_linkage_name: (indirect string, offset: 0xca): > _ZN8jvstatic6STATICE > <12b> DW_AT_type : <0x181> > <12f> DW_AT_external : 1 > <130> DW_AT_declaration : 1 > > Pursuant to the DWARF3 specification (sec 4.1 #6), I would expect to > subsequently see a DIE with DW_TAG_variable which refers to DIE <120> > (via DW_AT_specification). Alas, this DIE does not appear in the debug > info at all. > > Does java operate differently from C++ (which follows the DWARF > specification)? Only by mistake. gcj itself has no code to generate DWARF: we create the data structures and hope that the back end will do The Right Thing with them. I suppose that the C++ compiler generates something different from gcj. I don't know why. Andrew.