From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25629 invoked by alias); 13 Nov 2002 21:23:29 -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 25601 invoked from network); 13 Nov 2002 21:23:28 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 13 Nov 2002 21:23:28 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18C4yr-0005pm-00; Wed, 13 Nov 2002 15:23:26 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18C504-0001tJ-00; Wed, 13 Nov 2002 16:24:40 -0500 Date: Wed, 13 Nov 2002 13:23:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: Is gdb.c++/local.exp broken? Message-ID: <20021113212439.GA7081@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00154.txt.bz2 On Wed, Nov 13, 2002 at 03:56:42PM -0500, Jim Blandy wrote: > > The recent change to dwarf2read.c:read_func_scope causes the following > known failure: > > ! FAIL: gdb.c++/local.exp: ptype Local (gdb/483) > > to change to this unknown failure: > > ! FAIL: gdb.c++/local.exp: ptype Local > > The bug in the database, gdb/483, is that the type Local gets printed > incorrectly. But if you look at gdb/testsuite/gdb.c++/local.cc, the > type Local isn't even in scope at that point --- on line 59, after the > return of marker1. I don't think it should be printed at all. And in > fact, with the recent change to read_func_scope, that's what GDB does, > under Dwarf 2: > > Breakpoint 2, marker1() () at /home/jimb/cygnus/src/sourceware/gdb/gdb_5_3/src/gdb/testsuite/gdb.c++/local.cc:5 > 5 } > (gdb) up > #1 0x08048438 in main () at /home/jimb/cygnus/src/sourceware/gdb/gdb_5_3/src/gdb/testsuite/gdb.c++/local.cc:59 > 59 marker1(); > (gdb) PASS: gdb.c++/local.exp: up from marker1 > ptype Local > No symbol "Local" in current context. > (gdb) FAIL: gdb.c++/local.exp: ptype Local > > I kind of think the test should actually try to print Local while > stopped in the function `foobar', and print InnerLocal while stopped > in main, and check that Local isn't defined. That, however, > introduces a new failure in the STABS side, which still isn't scoping > Local correctly. > > Is my understanding of this correct? If I file a PR for the stabs > side of things, can I mark the STABS failure as a kfail, and commit > this change? While I can't approve testsuite patches, I can certainly confirm your reading of the testcase. If our current frame is in main, there's no reason Local should be considered to be in scope, and plenty of reason we should make sure that it isn't. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer