From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5071 invoked by alias); 17 Feb 2004 18:22:03 -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 4887 invoked from network); 17 Feb 2004 18:22:00 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 17 Feb 2004 18:22:00 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 14D452B92; Tue, 17 Feb 2004 13:21:58 -0500 (EST) Message-ID: <40325BC5.4090403@gnu.org> Date: Tue, 17 Feb 2004 18:22: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 , Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: [MI] -file-list-exec-source-files References: <20040213012946.GB4476@white> <20040216033008.GB2685@nevyn.them.org> <20040216034525.GA3437@white> <20040216034930.GA29864@nevyn.them.org> <20040216153329.GA3978@white> <20040216154628.GA996@nevyn.them.org> <20040216160835.GB3978@white> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00194.txt.bz2 > On Mon, Feb 16, 2004 at 10:46:28AM -0500, Daniel Jacobowitz wrote: > >> On Mon, Feb 16, 2004 at 10:33:29AM -0500, Bob Rossi wrote: > >> > Here is the problem I am trying to solve. >> > >> > Any front end needs to know the absolute path to the source files. From >> > what I can see, there are several ways of finding the absolute path. >> > In some cases, all of this info is needed. > >> > >> > So, basically, I am making an assumption, if GDB can not find the >> > absolute path to the source file, the front end can not. Is this true? >> > Also, why should the front ends do it, if it can be done correctly in >> > one place? > >> >> Then why are you trying to return symtab->dirname at all? Or have I >> misinterpreted you, and you were returning symtab->fullname? I don't >> think symtab->dirname should be exposed in this interface. > > > Yes, please excuse me. I am only interested in returning the fullname to > the front end. I agree with you, symtab->dirname is only useful > internally in resolving the fullname. > > >> > As far as I know, most existing front ends use annotate level 1-2-3 to >> > figure out where the source file is. I just want to simplify this >> > process, so that front ends can easily get the absolute path to the >> > source file without having to run multiple commands, like the CLI. > >> >> This sounds like the front end is only ever interested in one source >> file at a time, so that would be a more efficient design than asking >> GDB to provide fullnames for every source file at once. To badly generalize, front ends come in two flavours: - integrated IDEs such as eclipse where the front end thinks it knows everything - lighter weight debugger interfaces (Insight, xxgdb, ...) where, instead, GDB is relied on for the information In the latter case a full and correct list of file names is entirely reasonable. e.g., for a filename tab or filename browser. > Here there is several points to make. > > 1. The front should be able to get the fullname for a single source. > > -file-list-exec-source-file currently returns the fullname of the > currently executing file. Which btw, has already had it's symtab read > in. This is why symtab->dirname is set, and the fullname is accessible. > > An parameter should be added to -file-list-exec-source-file. So it can be > invoked like "-file-list-exec-source-file foo.c" > With this new command, the user should get the fullname of a particular > source file, which means reading in the symtab, or modifying the psymtab > to have the dirname in it. As the doco suggests, the command's spec came from knowing that equivalent functionality was required by Insight (see gdb_listfiles in that code base). I think -file-list-exec-source-files should take the wild card (and not -file-list-exec-source-file) because that is returning a list, its only a small jump to have it return a qualified list. Also ... > 2. The user should be able to get all of the fullnames with > -file-list-exec-source-files? > > Currently, -file-list-exec-source-files, prints all of the "filenames" > by looping through the symtabs and psymtabs. It knows the fullname to > most of the symtabs, and none of the psymtabs. So, for some files, it > prints the filename, along with the fullname, and for others it just > prints the filename. > > If it just lists the "filename" and the front wants the "fullname", it > can use the "filename" as the parameter to -file-list-exec-source-file, > which will return the "fullname". > > However, if the front end wants all of the fullnames, should we make it > send N commands to -file-list-exec-source-file, or should > -file-list-exec-source-files take an optional parameter to force it to > find all of the fullnames? (Yes, making a front end do that would be dumb :-) > Basically, this means, GDB will give you all the "filenames" (keys) of > the current executable. Then, if you want the "fullname"(value), use the > "filename"(key) as an argument to -file-list-exec-source-file which will > return the "fullname"(value). > > Hmmm, is this a little to confusing? ... I'd specify the interface such that it is expected to return fully qualified file names. I don't think anything less than that is useful. So ... what I think has been identified is the need for a symtab query that returns a list of the currently known fully qualified source files. How the symtab chooses to implement that query is a separate problem. This would of course make the implementation something like: mi_file_list_exec_source_files (..) char **source_files = symtab_lookup_source_files (); for all source_files generate MI output and likely a first draft based somewhat on existing code. Andrew