From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32390 invoked by alias); 4 Jun 2006 00:04:26 -0000 Received: (qmail 31547 invoked by uid 22791); 4 Jun 2006 00:04:24 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 Jun 2006 00:04:21 +0000 Received: from kahikatea.snap.net.nz (p202-124-112-201.snap.net.nz [202.124.112.201]) by viper.snap.net.nz (Postfix) with ESMTP id 6D875752442; Sun, 4 Jun 2006 12:04:21 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 043E01D3550; Sun, 4 Jun 2006 12:03:34 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17538.9045.370853.784139@kahikatea.snap.net.nz> Date: Sun, 04 Jun 2006 00:04:00 -0000 To: Daniel Jacobowitz Cc: Eli Zaretskii , susan@smacchia.net, jimb@codesourcery.com, gdb@sourceware.org Subject: Re: MI: -file-list-exec-source-files In-Reply-To: <20060603223537.GA3482@nevyn.them.org> References: <20060603004553.33821.qmail@web51812.mail.yahoo.com> <17536.58772.420434.491191@kahikatea.snap.net.nz> <17538.3165.636175.483701@kahikatea.snap.net.nz> <20060603223537.GA3482@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.19 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00016.txt.bz2 > > > As you see, there are two entries for myproc.c and two entries for > > > mytest.c, one with a NULL dirname, the other with a non-NULL dirname. > > > > Yes, I can see the duplicate entries > > But Eli's got a good point: the one with a NULL dirname is at best > sub-optimal. Can we just remove that one then? > > > Sounds like we should implement duplicate removal from the UI lists? > > > > I'm not sure. It may take GDB longer to remove the duplicate entries than > > it does for Emacs to read them. It would be best not to create them in the > > first place, but maybe that's not easily done. > > There are two potential sources of duplication: bugs, e.g. in our > processing of symbol vs. line information, and actual duplicate entries > in the debug info. As Susan correctly noted, the duplicates are often > legitimate and discarding them entirely would be bad. OK, I didn't realise that. How do we distinguish between these and those which aren't needed? Will the legitimate ones always have a non-NULL dirname -- Nick http://www.inet.net.nz/~nickrob