From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32276 invoked by alias); 3 Jun 2006 01:39:59 -0000 Received: (qmail 32267 invoked by uid 22791); 3 Jun 2006 01:39:58 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Jun 2006 01:39:55 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060603013950.UYKB26910.eastrmmtao05.cox.net@localhost.localdomain>; Fri, 2 Jun 2006 21:39:50 -0400 Received: from bob by localhost.localdomain with local (Exim 4.60) (envelope-from ) id 1FmL7H-0004yp-B6; Fri, 02 Jun 2006 21:39:51 -0400 Date: Sat, 03 Jun 2006 01:39:00 -0000 From: Bob Rossi To: Susan Macchia Cc: Jim Blandy , gdb@sourceware.org Subject: Re: MI: -file-list-exec-source-files Message-ID: <20060603013951.GB9640@brasko.net> References: <20060603004553.33821.qmail@web51812.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060603004553.33821.qmail@web51812.mail.yahoo.com> User-Agent: Mutt/1.5.11 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/msg00011.txt.bz2 > Perhaps, but in working on the UI for other debuggers, I have seen this and > it looked like the same situation. When I worked on Compaq ladebug, we had > to get the list of source files so that the user could choose one to set > bpts in, or to browse. In retrieving that list from the debugger, I saw e > xactly what Nick is seeing. And in delving into the internals of the > debugger/compiler, I found that the situation I described, with foo.? to > be why I saw more than one source. This is especially true for C++ when > templates are used. What you really want to see in a list like this is > "foo.c compiled this way", "foo.c compiled that way", and so on. I don't > think any debugger has solved this problem reasonably from a UI perspective. Even if this was true, I still think the duplicates make no sense with the information that -file-list-exec-source-files currently provides. The front end will use the file as is, so having 1 or N of those files just makes more I/O at this point. Bob Rossi