From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20865 invoked by alias); 31 Dec 2003 19:34:53 -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 20849 invoked from network); 31 Dec 2003 19:34:53 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 31 Dec 2003 19:34:53 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5D9B92B8F; Wed, 31 Dec 2003 14:34:52 -0500 (EST) Message-ID: <3FF324DC.2090801@gnu.org> Date: Wed, 31 Dec 2003 19:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Bob Rossi Cc: gdb@sources.redhat.com Subject: Re: -file-list-exec-source-files implementation References: <20031216001040.GA7871@white> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00307.txt.bz2 > Hi, > > I am working on implementing the -file-list-exec-source-files command > for the MI interface. I wanted to make sure the community liked my ideas > before I really got into it. I looked at sources_info in symtab.c to > find out how to implement the MI call. The only change I think would be > nice over the CLI interface is if the MI command gave the fullpath along > with the regular path that 'info sources' currently outputs. > > I currently have come up with 3 possibilities and wonder what's best. > > 1. I could make -file-list-exec-source-files always return the fullpath. > > 2. I could make -file-list-exec-source-files return the fullpath of > each file if a parameter was passed to the function. > > The obvious question with these 2 option's is if finding the fullpath > for each file is to costly of an operation to put upon each user of this > function. > > 3. The other option is to do it the way the CLI does it. It makes the user > do the 'info sources' to find the file of interest. And then do 'list > foo.c:1' and then 'info source'. After that, the CLI outputs the > absolute path to the file foo.c. I could make the user do > '-file-list-exec-source-files' to get the relative paths. Then the user > could do '-file-list-exec-source-file foo.c' to get the absolute path to > that file. > > I prefer the first alternative if it is possible to look up the fullpath > to all of the file's that the exe is made up of. This must be scalable > for even the largest executable's that GDB supports. > Does this sound reasonable? I don't really know how costly the operation > of looking up the fullpath to a file is in GDB. If it is not reasonable, > the third alternative will be the best way to go. > > Any suggestions? A guess is "yes". Return all of: - the short name - the relative name (from memory what's what is in the debug info) - the full name But possibly control the last one with an option. Relatively speaking, I don't think this is an expensive operation. I think having it modal (like you describe "info source"s current behavior) would just confuse things. And yes, as you and Eli note, having just the short name won't be much help - GDB should have and provide all the information needed to Andrew > Bob Rossi >