From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29594 invoked by alias); 7 Feb 2004 02:23:24 -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 29585 invoked from network); 7 Feb 2004 02:23:19 -0000 Received: from unknown (HELO lakemtao02.cox.net) (68.1.17.243) by sources.redhat.com with SMTP; 7 Feb 2004 02:23:19 -0000 Received: from white ([68.9.64.121]) by lakemtao02.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040207022318.BGXC19763.lakemtao02.cox.net@white>; Fri, 6 Feb 2004 21:23:18 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1ApI7q-00023Y-00; Fri, 06 Feb 2004 21:23:18 -0500 Date: Sat, 07 Feb 2004 02:23:00 -0000 From: Bob Rossi To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: -file-list-exec-source-files implementation Message-ID: <20040207022317.GA7882@white> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20031216001040.GA7871@white> <3FF324DC.2090801@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FF324DC.2090801@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-02/txt/msg00071.txt.bz2 > >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 Well, I have a patch, and I am ready for some suggestions. (the patch will be posted to gdb-patches) I provided the filename ( relative ), and the fullname (absolute) to the user. When the fullname can not be found by GDB, it will not get written out. Basically, I lifted some of the code from sources_info in symtab.c. It had the functionality I was looking for. In addition, whenever a fullname wasn't available, I attempted to look it up by using 'source_full_path_of' which is basically a wrapper around openp. For a simple program, that output of 'info sources' appears as, (top-gdb) info sources Source files for which symbols have been read in: Source files for which symbols will be read in on demand: /build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S, /build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crti.S, init.c, ../sysdeps/i386/elf/start.S, test.c For the new mi command, it looks like this, -file-list-exec-source-files ^done,psymtab_file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S",psymtab_file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crti.S",psymtab_file="init.c",psymtab_fullname="/home/bob/cvs/src/src/src/gdb/init.c",psymtab_file="../sysdeps/i386/elf/start.S",psymtab_file="test.c",psymtab_fullname="/home/bob/cvs/src/src/src/gdb/test.c" Any objections or suggestions? Bob Rossi