From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1831 invoked by alias); 13 Aug 2002 21:05:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1824 invoked from network); 13 Aug 2002 21:05:57 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 13 Aug 2002 21:05:57 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g7DL5nJ09239; Tue, 13 Aug 2002 14:05:49 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Jim Blandy Cc: gdb Subject: Re: DWARF-2, static data members References: <15700.15818.829204.767503@jackfruit.Stanford.EDU> Content-Type: text/plain; charset=US-ASCII From: David Carlton Date: Tue, 13 Aug 2002 14:05:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 X-SW-Source: 2002-08/txt/msg00125.txt.bz2 In article , Jim Blandy writes: > I agree with your reading. There should be *two* entries for a C++ > static data member: one as a variable definition, DW_TAG_variable, > at the top level, and one as a member definition, DW_TAG_member, as > a child of the struct/class/union die. Right. Though you can presumably skip the DW_TAG_variable entry if you're compiling a file in which that variable never gets defined or referred to. (E.g. if the file you're compiling includes a header file defining a class that it uses, but the file you're compiling doesn't happen to use that particular static member of the class itself.) > For what it's worth, the paragraph of the Dwarf 2 spec that > corresponds to paragraph 6. in Section 4.1 of Draft 3 rev 7 (what I > treat as authoritative for Dwarf 3) doesn't specify what tag the > type die's child is supposed to have. Good point: I'd missed that Dwarf 3 is more explicit there. Dwarf 2 seems to me to be explicit enough, in that the section on class declarations that says that data members should have the DW_TAG_member (with no exception for static data members), but it's a good thing that Dwarf 3 makes that clearer. > Have you run `readelf -wi' on the executable, or run GCC with > `-save-temps -dA' and looked at the .s file, to see what GCC is > actually generating? I think GCC does generate children of > struct/class types with the DW_TAG_variable tag. I'll have to look up what those arguments mean :-), but I did do g++ -S yesterday and went through the .s file by hand. (Fun, and educational, though I don't plan to do it too often.) It really is generating DW_TAG_variable tags instead of DW_TAG_member tags. > You might put together a fix for GCC, too --- dwarf2out.c is big, > but it doesn't seem too bad. This would allow you to actually test > your changes. I'll give it a look. I did submit a PR for GCC, so at least it's in their bug database. David Carlton carlton@math.stanford.edu