From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22159 invoked by alias); 13 Aug 2002 20:48:46 -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 22151 invoked from network); 13 Aug 2002 20:48:43 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 13 Aug 2002 20:48:43 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7DKcxb06613; Tue, 13 Aug 2002 15:38:59 -0500 To: David Carlton Cc: gdb Subject: Re: DWARF-2, static data members References: <15700.15818.829204.767503@jackfruit.Stanford.EDU> From: Jim Blandy In-Reply-To: <15700.15818.829204.767503@jackfruit.Stanford.EDU> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 Date: Tue, 13 Aug 2002 13:48:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00123.txt.bz2 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. This sort of corresponds to the way you have to actually declare a static member in C++. In the class definition you say: class C { static int foo; } and then somewhere else you must actually give the definition of C::foo: int C::foo; 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. I guess the entire GNU toolchain just guessed wrong. > Having said all that, when I run GDB on some code with static data > members that I'd compiled with GCC 3.1, the appropriate branches were > taken. Which means that either there's something I _really_ don't > understand about GDB's code (always a possibility!) or else GCC is > making the same misinterpretation and GDB. 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. > Nonetheless, I think they should both be fixed. It seems to me that > the safe thing to do would be to modify GDB so that it treats members > that either are DW_TAG_variable or DW_TAG_member + DW_AT_declaration > as static data members; that way it will be safe both with code > compiled by current versions of GCC and by code compiled with > hypothetical future versions of GCC that have this misinterpretation > fixed (as well as other compilers out there that might do the right > thing). I'd be happy to try to make this change if other people agree > with me. That sounds right to me. 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.