From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 831 invoked by alias); 16 Mar 2004 18:25:41 -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 699 invoked from network); 16 Mar 2004 18:25:40 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 16 Mar 2004 18:25:40 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 2A6E2C6CF; Tue, 16 Mar 2004 10:25:39 -0800 (PST) To: gdb Cc: Daniel Jacobowitz , Jim Blandy , Elena Zannoni Subject: Re: gcc 3.4 regression in gdb.cp/namespace.exp References: From: David Carlton Date: Tue, 16 Mar 2004 18:25:00 -0000 In-Reply-To: (David Carlton's message of "Mon, 15 Mar 2004 16:23:41 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg00149.txt.bz2 On Mon, 15 Mar 2004 16:23:41 -0800, David Carlton said: > I just ran the testsuite with g++ (GCC) 3.5.0 20040119 (experimental) > (which is right after 3.4 branched), and I get a regression on > gdb.cp/namespace.exp, on both mainline and 6.1. > ptype CClass::NestedClass > There is no field named NestedClass > (gdb) FAIL: gdb.cp/namespace.exp: ptype CClass::NestedClass I've done some poking around; here's the deal. * I haven't checked with new GCC versions (I can't connect to savannah.gnu.org), but I have verified that Daniel's patch caused the regression. * Recall that the setup is: Die 1: declaration for CClass. Die 2: definition for CClass::NestedClass. (Whether or not it's a good idea for GCC to generate DIEs like this is another matter, but it is, at least with the snapshot that I was using, and it seems to be legal.) When reading Die 1 (both within read_structure_type and within process_structure_scope), GDB notices that the die is a declaration, so it doesn't bother looking at Die 2. * This behavior is, however, the same as the old behavior of read_structure_scope. So how could Daniel's patch have caused a regression? The answer: further down we have: Die 3: DW_TAG_reference_type referring to Die 2 above. So we call read_tag_reference_type, which calls die_type, which calls tag_type_to_type, which calls read_type_die. Which used to call read_structure_scope (i.e. read_structure_type + process_structure_scope), but now only calls read_structure_type. Pretty subtle - I certainly wouldn't have been able to figure this out from looking at the source code alone. (But that's why we have GDB!) So what's the correct fix here? I tend to think that the code would be easier to understand if we only generated symbols while going through the code in the obvious tree order (calling functions named process_XXX, ideally), instead of while following various cross-references (which we would only do via functions named read_XXX, ideally). Is that a reasonable hope? If so, it seems like the correct fix would be to change process_structure_scope to call process_die on all of its children, whether or not the current die is a declaration. I'll play around with a patch like that - it should be safe, I hope, since process_structure_scope is only called from process_die, so we shouldn't be generating symbols twice. David Carlton carlton@kealia.com