From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27238 invoked by alias); 15 Sep 2004 22:11:06 -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 27216 invoked from network); 15 Sep 2004 22:11:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Sep 2004 22:11:04 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8FMAxpg009617 for ; Wed, 15 Sep 2004 18:11:04 -0400 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8FMAvr26304; Wed, 15 Sep 2004 18:10:58 -0400 To: Daniel Jacobowitz Cc: David Lecomber , gdb@sources.redhat.com Subject: Re: whodunnit? info sources now returns duplicates References: <1095243296.24882.5.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com> <20040915181008.GA14735@nevyn.them.org> From: Jim Blandy Date: Wed, 15 Sep 2004 22:11:00 -0000 In-Reply-To: <20040915181008.GA14735@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-09/txt/msg00131.txt.bz2 Daniel Jacobowitz writes: > On Wed, Sep 15, 2004 at 11:14:56AM +0100, David Lecomber wrote: > > This is a regression bug -- the version I have tested this are > > from CVS on 2004-08-17, and 2004-06-22. > > > > Any test program: > > > > foo/test.c > > > > int main() { > > int x; > > } > > > > now compile - but in the directory above foo. > > > > gcc -g foo/test.c > > > > run gdb ./a.out > > > > For 20040622, only foo/test.c is listed in info sources (correct) > > For 20040817 (and recent 20040913) foo/test.c and test.c are listed.. > > (incorrect) > > > > When you add a breakpoint to main, and do info sources, the duplicate > > vanishes.. > > > > Any takers? > > Joel's patch to dwarf2read to create symtabs based on the line table > also creates symtabs if the name of the compilation unit and the name > in the line table don't match. I noticed this last week and don't know > what to do about it. > > One workaround is a patch I whipped together to display the fullname in > info sources output (arguably more useful anyway). The two will have > the same fullnames and we already have code to suppress printing the > duplicates. Attached. > > What do you think? Looks good to me. If you've tested it, go ahead and commit.